+1 for the parent. As sysadmin in a french company running a public forum, I studied the law. Here are the interesting points:
Les données [...] que les personnes sont tenues de conserver en vertu de cette disposition, sont les suivantes : [...] 3 Pour [les founisseurs de forum/blogs...], les informations fournies lors de la souscription d'un contrat par un utilisateur ou lors de la création d'un compte : [...] g) Le mot de passe ainsi que les données permettant de le vérifier ou de le modifier, dans leur dernière version mise à jour ; [...] Les données mentionnées aux 3 et 4 ne doivent être conservées que dans la mesure où les personnes les collectent habituellement.
Which can be roughly translated:
Data [...] that must be kept are : [...] 3) For [forum/blogs/... providers] data given on subscription or account creation: [...] g) the password and the data that allows to check it or change it, in their latest version. [...] Data given in 3) and 4) must be kept only if they are usually kept.
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.
I couldn't stop thinking of existing theories and/or implementations of her ideas...
Modeling processes out of the OO paradigm (opposite to what Design patterns started to sacralize for example) is precisly the subjet of so-called business rules. But BR people are close to relationnal model of data, that is too quickly assimilated with SQL DBMS(*), so OO oriented people don't buy it (see the almighty impedance mismatch).
Data-structures other than trees and collections are already genericaly implementable in any modern OO language. See Eiffel for example which can perfectly do that for 15 years (parametric classes, with full type safety). May be the java generics will help to build highly reusable data structure... I doubt that, anchored type is missing (ie the possibility to declare the type of a variable as equal to another type, nearly mandatory when dealing with inheritance of generics).
Tom.
(*) I warmly recommend the writings of Chris Date and Fabian Pascal to really see how the relationnal model of data is different from SQL databases...see DBDebunk for references.
The Moon Project (Earth 2150 sequel) is such a game : you start with 2 "zones" (maps), one of which is your HQ. Every mission takes place in another zone and you can transport units between any of them. So all units you build are kept for future mission, provided that you have the patience to bring them back to the headquarter...
The Moon project is one of the most advanced RTS i've ever seen, in concepts... The company developping it sunk while it was at final stage of QA. you can see it in the extreme unbalancing of some maps/mission and the sudden raise in difficulty from one mission to another.
Anyway, judging from what the genre has become with CnC : Generals, I understand that one can be bitter... I am.
Slashdot Mirror
+1 for the parent. As sysadmin in a french company running a public forum, I studied the law. Here are the interesting points :
Les données [...] que les personnes sont tenues de conserver en vertu de cette disposition, sont les suivantes :
[...]
3 Pour [les founisseurs de forum/blogs...], les informations fournies lors de la souscription d'un contrat par un utilisateur ou lors de la création d'un compte :
[...]
g) Le mot de passe ainsi que les données permettant de le vérifier ou de le modifier, dans leur dernière version mise à jour ;
[...]
Les données mentionnées aux 3 et 4 ne doivent être conservées que dans la mesure où les personnes les collectent habituellement.
Which can be roughly translated :
Data [...] that must be kept are :
[...]
3) For [forum/blogs/... providers] data given on subscription or account creation:
[...]
g) the password and the data that allows to check it or change it, in their latest version.
[...]
Data given in 3) and 4) must be kept only if they are usually kept.
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.
;) . 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.
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
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.
I couldn't stop thinking of existing theories and/or implementations of her ideas...
Modeling processes out of the OO paradigm (opposite to what Design patterns started to sacralize for example) is precisly the subjet of so-called business rules. But BR people are close to relationnal model of data, that is too quickly assimilated with SQL DBMS(*), so OO oriented people don't buy it (see the almighty impedance mismatch).
Data-structures other than trees and collections are already genericaly implementable in any modern OO language. See Eiffel for example which can perfectly do that for 15 years (parametric classes, with full type safety). May be the java generics will help to build highly reusable data structure... I doubt that, anchored type is missing (ie the possibility to declare the type of a variable as equal to another type, nearly mandatory when dealing with inheritance of generics).
Tom.
(*) I warmly recommend the writings of Chris Date and Fabian Pascal to really see how the relationnal model of data is different from SQL databases...see DBDebunk for references.
The Moon Project (Earth 2150 sequel) is such a game : you start with 2 "zones" (maps), one of which is your HQ. Every mission takes place in another zone and you can transport units between any of them. So all units you build are kept for future mission, provided that you have the patience to bring them back to the headquarter...
The Moon project is one of the most advanced RTS i've ever seen, in concepts... The company developping it sunk while it was at final stage of QA. you can see it in the extreme unbalancing of some maps/mission and the sudden raise in difficulty from one mission to another.
Anyway, judging from what the genre has become with CnC : Generals, I understand that one can be bitter... I am.
Tom.