Re: Databases as objects
- From: frebe73@xxxxxxxxx
- Date: 3 Jan 2007 10:52:32 -0800
.....I consider SQL to be a low level language, as far as RDBs are
concerned, because it is application-ignorant. It's like C for
relational operations. SQL doesn't know anything about my application.
It is the ability of a language to assimilate a business'
vocabulary that moves it from being 1st, 2nd, or 3rd-level language and
if not becoming 4th-level, at least makes it a large value of 3.
Isn't SQL able to assimilate to business vocabulary? A view definition
might be very application-specific.
Au contraire. When I add procedures for doing a business-specific thingWhy access it from applications
using the same domain-ignorant language? Instead, I construct
procedures that create a domain-specific interface.
Isn't the database schema already a domain-specific interface? Your
procedures won't make it more domain-specific.
I make my Semantic Persistent Store (discussed elsewhere on this thread)
more aware of the semantics of my business.
Are you saying that a database schema is not domain-specific? What
about
create table order (orderid integer, customeridid integer, order_date
date)
You know, that's the problem with simplified examples. People tend notInstead of the
lower-level
select * from account, user where user.userId=X and account.userId =
user.userId
when instead I can use
exec getAccountsFor @userId=X
?
Besides its brevity, the procedure name clearly communicates the intent
of the operation (stbpp pattern: intention revealing message),
Doesn't the word "select" clearly communicate the intent of the
operation?
to extrapolate the simple example into a more complex one. Yes, the
word SELECT does indicate you're doing a query, but what exactly is
being queried and the rules expressed by way of table names, joins, and
discriminations tend to obfuscate the intent. No matter how complex a
SELECT may be (or several selects) the procedure's signature should be
simpler to read.
If you have a complex select statement, define a view. That is much
more flexible than hiding the select statement behind a procedure.
It seems odd to me that programmers accustomed to creating functions in
their own code to add structure, increase readability and reuse resist
doing the same for their databases.
Views are an excellent way or increasing readability and reuse.
Telling, perhaps, but not "obvious". Though you might be given a cluemakes obvious its parameters,
If you can read the schema definition, the parameters are already
obvious.
as to the nature of my business by looking at the tables are you
prepared to assert you can correctly update the tables?
Yes. Input validation should be defined as referential and check
constraints.
You could do that, but I wouldn't. If a single SELECT can satisfy bothand provides a layer of indirection behind which
its implementation can change without affecting the procedure's users.
But you also makes it all very inflexible. In your example, you select
all columns in the account and user tables. Lets say you are only
interested in some of the columns or other columns from a third table,
you need to create a new procedure that are almost identical to the
first one.
then I can update the existing procedure to include the new fields and
now both may use it.
That means you will always execute the join, even if you are not really
interested in the joined values? This is one of the reasons why your
solution is a major performance drawback.
You and I are not using the same definition of level. See my
description above.
Your definition of high-level is application-specific. Using that
definition it is not possible to see any difference in level between
assembler and Java. Both can be used for making application-specific
procedures.
My definition of level is the amount out code you have to write to
perform a given task. Java source code will in almost all situations
have lesser lines of code than a corresponding assembler source code. A
SQL source will have less LOC than the corresponding Java source.
Your procedures are indeedIs that how you think of your objects. That the data inside them is
domain-specific but so are the schema, your procedures didn't
contribute to anything.
domain specific enough that methods don't add anything useful to them?
The database schema is domain specific, but that doesn't contradict the
fact that procedures may add anything useful.
The procedures are written in some language andThey're language neutral in the sense they can be equitably invoked and
need to be called using a specific technology, so I can't understand
how you can claim them to be language-neutral.
their results accessible to C, Java, Smalltalk, Perl, PHP, LISP,
FORTRAN, etc. It doesn't matter which language the procedure is called
from, the results to the database (object) are the same.
You can call SQL code from C, Java, etc too.
Claiming that proceduresNot true. They are paradigm neutral in the sense both their invocation
are paradigm-neutral is not really correct either.
and results are understandable by aspect-oriented, functional,
object-oriented, and structured languages. Procedures don't reserve the
benefits of their existence to OO-only languages or XML-capable
languages or any other exclusive feature a language may support. The
bar is set deliberately by APIs so as not to discriminate against client
languages and environments.
Procedures does not exists in OO. The closest thing to a procedure is a
static method. Functional languages does not accept procedures with
side-effects (insert or update), or procedures returning values not
derived from the arguments.
I don't know which DBMS you're using, but most modern DBMSs supportTo find all the places in my application source code that get account
information with user IDs it is much easier to find senders (callers) of
getAccountsFor than it would be to find all the SQL referencing both the
account and user tables.
But getAccountsFor is not the only procedure that uses the account or
user tables. How do you know which procedures that uses which tables?
reflection in the form of system tables and functions that can answer
the question, "which procedures use table x?" in the same way modern OO
environments can answer the question, "which methods access instance
variable x?" or "which methods call the method f(x)?" or "who implements
the method f(x)?"
An IDE (or even grep) could solve the same problem if you embedd the
SQL statements in your application code.
Again, I doubt that's how you create your OO code, ".. any [method] canCould the latter be done? Sure, but when a
more efficient and accurate alternative exists why would you?
Why is it so important to "To find all the places in my application
source code that get account
information with user IDs"? Your assumption that it is more efficient
using your way is only true, if it only exists one or a few procedures,
performing this task. Because any procedure can do the same task, I
don't find your more more accurate. You basically need to browse the
implementation of all procedures.
do the same task.." I suspect that like many good OO designers you
don't have multiple methods that do the same thing for any given class.
How many methods are their to add days to a date? Even if they take the
same number and types of arguments would you create multiple method with
different names?
Your approach will result in a rather large number of procedures. When
a new database query is needed, the programmer has to browse many of
the existing procedures to see if the same or a similar query is
already implemented. I have experienced many times that programmers
choose to add a new procedure without carefully verifying if some
existing procedure already might do the job. There are also probable
that you will end up with many similar (but not identical) procedures.
/Fredrik
.
- Follow-Ups:
- Re: Databases as objects
- From: topmind
- Re: Databases as objects
- Prev by Date: Re: Use Case Scenario Inheritance
- Next by Date: Re: Databases as objects
- Previous by thread: testing .net code with FitNesse
- Next by thread: Re: Databases as objects
- Index(es):
Relevant Pages
|
