Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

> For a trivial example, consider an application that needs to somehow
> authenticate users (because different users have permission or not for
> different parts of the functonality of the application. The user
> information (name, password, etc) will have to be stored somewhere - a
> relational database might be an excellent place, in particular if this
> application is essentially a stand-alone one.
>
> However, it might be that the application is intented to be integrated
> into an existing infrastructure, that has user information stored in an
> LDAP-accessible database; or for another example, the user information
> might be stored in a Unix-style flat file (a la /etc/passwd).

Yes, authentication data may be stored in older obsolete hierachial databases (LDAP). Using a pluggable solution is a good strategy here, like JAAS if you are using Java. But I have never seen any authentication solution were you actually get username and password from the store. Instead you ask a serverice if your username/password pair is correct or not. In this case, the interface sould not be between the application and the database, but between the application and a pluggable service.

There might be other examples there some data by techical reasons need to be stored somewhere else but a SQL database, but that is still not an argument for separating all SQL statements by default.

Actually it would also be possible to write an own ODBC driver catching the SQL statements accesing the "user" table and call the LDAP database instead. (I have done a similar solution while converting stored procedures to Java. The client still thinks it is calling a stored procedure in the database using "execute procedure abc()". But the ODBC realized that this is not a database call and calls the appropiate java method instead.)

Fredrik Bertilsson
http://frebe.php0h.com Received on Thu Jun 01 2006 - 14:40:01 CEST