Re: [sqlite] Table within a table??

Darren Duncan wrote: > > Being that arrays *are* relations, you can use all the relational > operators on them. > Just to be totally clear - an array is not a relation. An array has fixed order of each dimension (eg columns and rows), and you address it by position. A relation is

Re: [sqlite] Table within a table??

> Jay A. Kreibich wrote: >> On Tue, Nov 03, 2009 at 02:51:23AM -0800, CityDev scratched on the wall: >>> That just seems so contrary to the original idea of the relational >>> model that you shouldn't have any data whose meaning is not defined >>> by data (in the case of an array you need to

Re: [sqlite] Table within a table??

Jay A. Kreibich wrote: > On Tue, Nov 03, 2009 at 02:51:23AM -0800, CityDev scratched on the wall: >> That just seems so contrary to the original idea of the relational >> model that you shouldn't have any data whose meaning is not defined >> by data (in the case of an array you need to understand

Re: [sqlite] Table within a table??

On Tue, Nov 03, 2009 at 02:51:23AM -0800, CityDev scratched on the wall: > > Whilst it's true that SQL isn't essential for a relational database More to the point, any database that supports SQL does not, and cannot, support the data typing and data manipulation rules set out by the

Re: [sqlite] Table within a table??

On Tue, Nov 3, 2009 at 4:51 AM, CityDev wrote: > I'm interested in your remark that relational databases now cope with > 'arrays'. Personally I've never seen that in DB2, Jet or SQLite. That just > seems so contrary to the original idea of the relational model that you >

Re: [sqlite] Table within a table??

Thank you for this response, Jay, and your other long one. They seem very well informed and helpful to the general practitioner. And "Database in Depth" is indeed a great book, and should be read by anyone wanting to understand databases; despite the name, it is actually quite approachable.

Re: [sqlite] Table within a table??

On Sun, Nov 01, 2009 at 01:23:52PM -0800, CityDev scratched on the wall: > > Darren Duncan wrote: > > > > Or at least it is in the version of the relational model > > that allows non-scalar attribute values, but that is the one that Chris > > Date et al, as well as myself ascribe to. > > I

Re: [sqlite] Table within a table??

Darren Duncan wrote: > > > Or at least it is in the version of the relational model > that allows non-scalar attribute values, but that is the one that Chris > Date et > al, as well as myself ascribe to. > > I didn't read this through but I recall Chris Date defining a relational

Re: [sqlite] Table within a table??

On Nov 1, 2009, at 2:32 AM, Jay A. Kreibich wrote: > Anyways... I've gone on long enough. Good luck with your design. > Think a bit, ask good questions, and hopefully we can all see > a different point of view and learn to see something new. Excellent post, thank you :) Along the same

Re: [sqlite] Table within a table??

+1 Jay, for explaining. another +1 for explaining so well. yet another +1 for explaining in such detailed. Heck, if you had written such a long post full of nonsense, you should have gotten +1. Since you wrote such a long post that is so useful and helpful to probably everyone, your post should

Re: [sqlite] Table within a table??

On Sun, 1 Nov 2009 02:27:16 -0400, mark m wrote: > P.S. your developer vs. database perspective should be > a sticky or FAQ for other newbies on this mailing list. If Jay allows (I'm sure he does), feel free to add an entry to: http://www.sqlite.org/cvstrac/wiki The

Re: [sqlite] Table within a table??

Well, you pretty much guessed right on just about everything going through my head. I am brand new to database programming and have been trying to learn just enough to accomplish what I want to do within my own app. The app I'm working on has evolved over the years into something that could now

Re: [sqlite] Table within a table??

On Sat, Oct 31, 2009 at 01:13:31AM -0400, mark m scratched on the wall: > O.K. I think I am starting to get the idea. It is just so foreign for me > to organize things this way. A master work history table for all cases > almost seems confusing. It will just take a bit of adjustment for me >

Re: [sqlite] Table within a table??

O.K. I think I am starting to get the idea. It is just so foreign for me to organize things this way. A master work history table for all cases almost seems confusing. It will just take a bit of adjustment for me to "trust" the database way of doing things. Text files organized in the way I

Re: [sqlite] Table within a table??

mark m wrote: > Thanks very much!! It also occurred to me that I could have a Table named > "case1" and another > named "case1workhist". The RDBMS wouldn't know they were related but my > application could be > set up to know this. > > Here is more detail on my current data organization: > >

Re: [sqlite] Table within a table??

On Fri, Oct 30, 2009 at 2:41 AM, mark m wrote: > Thanks very much!!  It also occurred to me that I could have a Table named > "case1" and another > named "case1workhist".  The RDBMS wouldn't know they were related but my > application could be > set up to know this. Expand

Re: [sqlite] Table within a table??

Thanks very much!! It also occurred to me that I could have a Table named "case1" and another named "case1workhist". The RDBMS wouldn't know they were related but my application could be set up to know this. Here is more detail on my current data organization: Open Cases Case 1... Case

Re: [sqlite] Table within a table??

mark m wrote: > I'm very new to database programming so this question is pretty basic > > I have data that is currently organized as follows: > > Each case has several fields that contain only one value. There are several > fields that have a pipe-delimited string > that represents a work

[sqlite] Table within a table??

I'm very new to database programming so this question is pretty basic I have data that is currently organized as follows: Each case has several fields that contain only one value. There are several fields that have a pipe-delimited string that represents a work history. Each work history