+1 for the parent. As sysadmin in a french company running a public forum, I studied the law. Here are the interesting points :

Which can be roughly translated :

As the MD5/SHA1 hash is a "data allowing the password to be checked", and the password in plain text might be among the data that are not usually kept, hashed passwords are perfectly legal way of keeping authentication information. The only obligation is to keep authentication information for one year, in any form.

However, the law forces to give it out to authorities on demand... As I think that MD5 cracking is not an big issue anymore, services providers willing to bring a hign level of confidentiality to they users should switch to higher security schemes.

I have not seen yet in this thread the link between domains and NULL.

In a relationnal approach, any value that can be NULL (in an SQL application) can either be put in a separate relation/table with a foreign key (it is an additionnal property) or included in a specific domain (as an expected value, ie : domain surname is string or the special value N/A). If your properly define a domain that has a specific, meaningfull "NULL" value, you should also provide operators to deal with it, in particular '=' (comparison). Consider the NULL=NULL comparison : it can be answered by either True, or False, or Unknown. Having a special value for a domain make the result of the comparison predictable and non-dependend of what the DBMS "thinks" of NULL !

Hence the problem with SQL is that you have no facility to build domains and the NULL value, and not the opposite !

Concerning updatable view, the point I've seen raised by relationnal proponents is that updating total is not "impossible", but that should be rejected by the DBMS iff it breaks view definition. So operation-defined attribute/column can be updated as long as it still has the expected value.

Sure it's a theorical approach but it allows to make every view updatable and to go to the real question : how to make every view updatable ? At that point, you are hit by other SQL deficiencies, In particular the fact that SQL rows are not unique in a table (definition of a key is not mandatory)...

On integrity constaints, I do agree that application should not make any bad query ;) . But the point of a DBMS is to ensure that every data stored is sound and valid. I've read proposals to build a constraint engine in DBMS, that just pass to applications the constraints attached to insertion (in a complex insertable view...). That could make integrity checks easier to implement in multiple applications and multiple languages. Think also that you always can replace a badly designed application, but that is is nearly impossible to re-insert wrong data, especially 2 or 3 years later.

Also a more thorough implementation of constraints will make query optimisation more aggressive in a few cases (as in any system : there is more optimisation opportunities if the system "understand" what you are talking about)

Also the missing "support for complex integrity constraints" should be read as a no-no for integrity triggers. Triggers are a way to specify "how" to check integrity and not "what" to check. Most people on that point would like pure declarative integrity constaints. It also goes in the same direction of telling the DBMS what you are trying the store.

Thomas.