Re: Counting propositions

x wrote:
> If there is something like count(distinct *) , it count "propositions"
> No matter how you modify the relation, it count "propositions"
> If you use count(distinct a,b,c) you count distinct (a,b,c) tuples no matter
> how you modify the relation (if a,b,c remains unaltered).

OK. But it's generally considered to be bad practice to use "select *" in production code; rather you should explicitly list all the columns. If you add an extra column it means the query needs changing possibly, but the advantages outweight the disadvantages I guess.

Isn't "select count(*)" a similar thing? You should explicitly name the data columns you want. If you change the candidate keys it may change the whole interpretation of the propositions. In which case it may no longer be true that you want to count propositions.

For example say you have a relation that has one row per invoice and you use count(*) to count the invoices. Then you change your design to allow multiple invoice lines per invoice, so you add an extra column to the primary key. Now your "select count(*)" query will return incorrect results, but "select count(invnum)" will still be correct.

Maybe not the best of example but it's just for pedagogical purposes!

I guess if you add a column to a relation it may change the whole meaning and granularity of the underlying predicate, or it may just add an extra bit of information but leave the basic meaning of the predicate intact. So I think "select count(*)" could be a dangerous shortcut in the same way that "select *" is.

So the point you make above could be seen as an advantage just as much as a disadvantage.

Paul. Received on Tue Jun 22 2004 - 15:41:19 CEST