Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Thu, 01 Jun 2006 23:39:23 GMT
Message-ID: <LUKfg.16278$A26.376787_at_ursa-nb00s0.nbnet.nb.ca>
Christian Brunschen wrote:
> In article <1149165601.331313.237840_at_u72g2000cwu.googlegroups.com>,
> <frebe73_at_gmail.com> wrote:
>
>>>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).
>
> LDAP is not usually considered 'obsolete'. For its specific purpose it
> appears to be fairly well-liked and in widespread use.
>>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.
>
> The interface should indeed be between the application and a pluggable
> service - but the database can be exactly such a pluggable service. SQL
> itself is a shared, well-defined common interface that permits using many
> different vendors' database implementationas as pluggable services.
>
> In the case of authenticating a user, when using LDAP as a back-end there
> might be a pre-existing 'authenticate this user in this LDAP database'
> operation available, which could be used to almost directly implement out
> 'wrapped' user authentication service; when using a SQL RDBMS as the
> back-end, we might store a one-way-encrypted version of the password in a
> column of the user table, and perform authentication with a 'select name,
> password from user where name = foo and encrypted_password = xh54k' query.
[snip]
>>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.
>
> The reason for separating SQL statements from the application code is the
> same reason as for generally writing functions/procedures/methods.
But I fail to see how abstractions separate anything from the application. The definitions of the functions/procedures/methods remain part of the application.
[snip]
>>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.
>
>
> ... basically putting an SQL front-end on an LDAP database, in order to
> be able to use SQL as a common database interface? That's certainly one
> solution. My preferred solution is to define a higher-level interface that
> is then implemented using whatever each database's most appropriate
> interface is.
How does one create a higher-level interface in a lower-level language? Do you likewise recommend implementing higher-level interfaces to your C/C++/Java/OO-du-jour in assembler?
The end result is essentially the same: There's a sihgle,
> well-defined interface through which we can work with the data as
> necessary from the point of view of the application.
[snip]
>>(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.)
>
> Cool. One could consider what you are doing as basically implementing an
> RDBMS with an SQL interface, which just happens to delegate a lot of its
> functionality to a second, pre-existing RDBMS with an SQL interface; not
> entirely unlike using the Facade design pattern.
So, I take it you consider expending considerable effort to re-invent existing services "cool" ? Does "cool" justify the expense? Are you the one actually paying for "cool" or is that someone else? Received on Fri Jun 02 2006 - 01:39:23 CEST