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
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.
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
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
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 them and
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 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.
Heh,
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
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 you're
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
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
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:
objIDownerflagsparamscode
Where code is a text
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 to:
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
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
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
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
17 matches
Mail list logo