, October 01, 2008 9:10 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] seeking storage design assistance
Stephen Woodbridge wrote:
> It also helps to know how you want to access/manipulate your data and
> what you want to do with it in SQL versus with your application. For
>
Stephen Woodbridge wrote:
> It also helps to know how you want to access/manipulate your data and
> what you want to do with it in SQL versus with your application. For
> instance, you could just store all the cad data as a blob, along with
> the attributes in columns.
Steve,
Hmmm... That's an
Jeffrey Becker wrote:
> ORM is always a tricky business. My experience is that unless the
> entity is very very simple, it's often inappropriate to attempt to do
> 1 row = 1 entity mapping. If things are collections of points, then
> by all means have a points table. A lot of this type of stuff
It also helps to know how you want to access/manipulate your data and
what you want to do with it in SQL versus with your application. For
instance, you could just store all the cad data as a blob, along with
the attributes in columns.
Then you can fetch the data based on attributes, and manipu
ORM is always a tricky business. My experience is that unless the
entity is very very simple, it's often inappropriate to attempt to do
1 row = 1 entity mapping. If things are collections of points, then
by all means have a points table. A lot of this type of stuff can be
made easier by 1) reall
Hi All,
I've got some general db storage design questions that I hope someone
can offer some advice on...
I have a need to store some CAD-type geometry in a SQLite database, and
I'm trying to decide on the best db design. Specifically, I need to
store "entity" data, which will include such th
6 matches
Mail list logo
