Re: In an RDBMS, what does "Data" mean?

"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote:

>Sir:
>
>This is a good question.
>
>"Laconic2" <laconic2_at_comcast.net> wrote in message
>news:t6adncXPEMhfsVfdRVn-sw_at_comcast.com...
>>
>> There's a second question, along the same lines.
>>
>> In the recent Pick example, showing an invoice, there's a list of
>account
>> numbers, and a correlated list of amounts.
>> That is, the second amount "goes with" the second account number. But, in
>> the earlier pizza pick example we had a list
>> of three toppings and an uncorrelated list of three cheeses. Now my
>> question is this: how the heck do you know that in one case the two lists
>> are correlated and in the other example they are uncorrelated?
>>
>> Are you "just expected to know" the logical structure of invoices and
>> pizzas enough to draw this inference?

     From what Bill H wrote below, it appears he thinks so.

>> Not that there aren't things you "just have to know" in a schema of
>tables,
>> but the Pick people treat it as though it's "intuitively obvious". Maybe
>to
>> an SME, but maybe not to everybody else.
>
>The database side doesn't normally enforce this relationship (it could be
>enforced with a trigger). However, considering the number of business rules
>associated with such a module, and the fact that the data is usually managed
>from a single application, these rules are best kept in the application
>code. This is because the business person is much closer to the application

     Every application module that deals with that relationship is going to have to have that code. If just one of them gets it wrong, trouble. If the rule changes, trouble.

     That is why it would be better to put it in the database. Do it once, and do it right.

     I have an app where I do not have the integrity rules coded in the database. It is all in the application code. It is biting me very badly right now. It made sense at the time (or rather more accurately, it did not make as much non-sense at the time), but I am certainly feeling it now.

     Now, when I go to change code of this sort, any that is in more than one place is taking me a lot of time to change.

     It starts off being easy to make changes, and then it gradually grows to the point where it is not so easy. Then, it can get rather awkward.

>and database, and its tools. The database nomenclature is not unique and
>words mean what they've always meant (i.e. noone refers to a "row" or a
>"column" when referencing a customer or a list of their outstanding
>invoices).

     No one? You are sure that it is impossible? "This column is..." or "This row has the subtotals for...".

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:

     I have preferences.
     You have biases.
     He/She has prejudices.