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 the >> significance of relative position - remember relations have no row >> or column order to stop you playing that game).
So what is a character string then? An *ordered* sequence of characters. And yet this coexists just fine with the relational model. An "array" is just a generalization of this concept. > Yes, EXACTLY. > > And so it is for nearly any other compound datatype. > > Arrays have implied ordering. You can't JOIN against an array > without extracting meta-data like that. Even if you do that, you > have to pair that data together and carry it through any manipulation. > If the data gets separated or lost, both sets of data becomes > worthless. Not Relational. Same is true of any other container > with an inherent ordering or listing (which is most of them). I see no problem supporting arrays in the relational model because you can define an array in terms of a relation. For example, an array can be any relation that has an explicit attribute, say call it "index", which defines the conceptual order of the elements, which are defined using the remaining relation attributes. Being that arrays *are* relations, you can use all the relational operators on them. And so an array-valued attribute *is* an RVA. Of course, you'll want to be careful in how you use the array-relations so that you keep the index-defining attribute where you need to. But this is the same as with any other important attributes, such as person name or person id or SIN whatever you need in the context. (Similarly, you can implement a bag/multiset over a relation by just having an explicit attribute to count instances, say call it "count".) Using the above methodology, it is perfectly valid to have an "order by" in the relational model; the result of an order-by operation is a relation that is like its main input relation but with an extra indexing attribute added. Note that the RANK operator one can find in math or SQL is essentially the same thing. And "limit" is just a slice/restriction/semijoin on a relation with an ordering attribute, that filters on the value of the indexing attribute being in a certain range. Such is one way that my Muldis D language supports the actual relational model while at the same time supporting all the useful things programmers want to do, and that SQL can do. >> So I still go back to point i) - you don't need to do this. > > I hope not, as my main point was that I feel they aren't allowed > under the Relational Model. I agree with your thoughts, I just think > there is a more rigid way of showing it to be true. > > But that doesn't mean people don't want them. Indeed. There is a lot of data where it makes sense to be ordered. But then, doing it properly in the relational model is encoding that desire as *data*, such as my above example does. > The point you're getting at is still valid, however. One aspect of > the Model is that a system can *physically* store the data in all > kinds of interesting ways because all the transforms are 100% > reversible. You don't really need to store the table, as defined, in > any physical way as long as you can compute it from the data you've > stored. RVAs, as a data modeling idea, fit right into that because > the only real difference between an RVA and a non-RVA is how you > write the data out on the display. Absolutely, and that's one of the best features of the relational model. That it gives users a lot of flexibility while implementations have a lot of flexibility to optimize behind the scenes, while they can be confident this optimization won't change the results users get. Not so much with SQL. -- Darren Duncan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
