michael munson schrieb:
Type refers to an int value that represents an in-server datatype. The
main difference is that I realized that I wouldn't necessarily need a
row for EVERY property, only if a property is different than the value
stored on the parent object. If its the same, it can
You guys have been a lot of help. This is the idea I've gotten from the
discussion we've had.
Three tables:
1) Method table
I did not mention this, because I pretty much already had the idea down.
It will have the following columns:
Where is a text entry that has stored some code
Marten makes good points. I would go further and suggest that you look
at creating your own API and DB primitives for your application. Often
you will find that trying to shoehorn general purpose tools into tightly
specific applications is as much effort as rigorously defining the
problem
Teg schrieb:
Hello Marten,
Monday, January 16, 2006, 2:14:59 PM, you wrote:
To me duplicate entries or near duplicate entries in a table are a
no-no. Sounds to me like you're talking about inserting the object
multiple times in the same table each instance describing one
"property" of the
Hello Marten,
Monday, January 16, 2006, 2:14:59 PM, you wrote:
To me duplicate entries or near duplicate entries in a table are a
no-no. Sounds to me like you're talking about inserting the object
multiple times in the same table each instance describing one
"property" of the object.
What
Teg schrieb:
Hello Marten,
I wasn't suggesting one table for all object, I was suggesting a table
for objects and a table for object properties. Using the object ID as a way
to identify which properties belong to what objects in the properties
table. The "Vertical" part was simply for the
On Mon, Jan 16, 2006 at 04:11:47AM -0600, michael munson wrote:
> >At the worst that would be around 6 million columns on a property table.
> >I've not used SQLite with tables that large before
> >so I'm not sure if searching with 2 index values (name, and object its on)
> >is going to be slow.
Hello Marten,
I wasn't suggesting one table for all object, I was suggesting a table
for objects and a table for object properties. Using the object ID as a way
to identify which properties belong to what objects in the properties
table. The "Vertical" part was simply for the object properties
On 1/16/06, michael munson <[EMAIL PROTECTED]> wrote:
> Well, the main reasons I want to use a database as opposed to some other
> type of arbitrary formatted file is real time access.
> In the sense that I won't have to read the entire file into memory and can
> just request objects as I need
Just some additional comments:
The "vertical" approach (described by Teg) leads also to a very
untypical relational
database and if a pure sql administrator would look at it .
Ok, but it works, but when using a vertical approach you have consider some
points:
* you have to throw away the
Indeed it may be questionable to use SQLite for stuff like this, but its a
very fast relational db library - and therefore it can be used as any other
relational database to store objects.
What is needed is very simple: you need a object-oriented relation database
wrapper - either as a
At the worst that would be around 6 million columns on a property table.
I've not used SQLite with tables that large before
so I'm not sure if searching with 2 index values (name, and object its on)
is going to be slow.
Heh, that should obviously read '6 million rows' . Sorry, its early.
What about defining a table called 'properties'. It would have a key
to link to the object and 'name' and 'value' column for each object
property. You could have as many properties as desired for each object
and they need not be the same for each object.
That could be a solution, but at the upper
On 1/14/06, michael munson <[EMAIL PROTECTED]> wrote:
> Greetings,
> I'm a bit new to SQL and SQLite so pardon me if I ask silly questions but I
> have run into a bit of a wall while attempting to design a database for a C++
> program I am attempting to write.
>
> The needs of the database are
Thanks, I'll pick it up.
The first thing to ask yourself here is whether or not it makes sense to
use a database. Certainly that makes sense if you need concurrent read
and write access, but if you only need to write from one source at a
time an XML file sounds more like what you need. It
michael munson wrote:
> Greetings,
> I'm a bit new to SQL and SQLite so pardon me if I ask silly questions but I
> have run into a bit of a wall while attempting to design a database for a C++
> program I am attempting to write.
>
> The needs of the database are to: represent an object oriented
Hello michael,
If I was doing that, I'd have another table of nothing but "properties".
Each property would have an integer that represents which object the
property belongs to. In that way, there's no limit to the number of
properties you can assign to an object. In the case of your
parent/child
Greetings,
I'm a bit new to SQL and SQLite so pardon me if I ask silly questions but I
have run into a bit of a wall while attempting to design a database for a C++
program I am attempting to write.
The needs of the database are to: represent an object oriented hierarchy of any
number of
18 matches
Mail list logo
