Re: 3vl 2vl and NULL

dawn wrote:
...
>
> I think of modeling data with both tags (domain names) and values.
> Take a simple screen for displaying a person's first name, last name,
> all values for e-mail address and first names of all children. We can
> surely model this data with multiple relations and we could also use a
> single relation with nested relations to model it if we add in data for
> ordering, but we cannot model this view of the data with an SQL view.
> We could potentially have a cartesian product view that includes all of
> the data for the screen, but it does not use the same data model as the
> view. The data model for the screen is not in 1st normal form and SQL
> requires 1NF.
> ...

The general idea has always made a lot of sense to me. If the program is querying and updating relations and the user is doing the same, what's the point of chopping up the db relations to put them on a screen and then putting them back together in the db after the user makes a change?

I've often wondered why I couldn't just assign a relational expression to the 'screen', as if the screen were a db in its own right. I wouldn't want to limit things to products either. I suppose current products would need to be more enlightened as to how to materialize joins and unions.

paul c. Received on Fri Jan 06 2006 - 16:22:09 CET