Re: Base Normal Form

dawn wrote:
>
> While the average comp sci major can figure out relations from the way
> it is typically explained, I don't like the way we have carved out the
> dbms from the rest of the application, modeling stored, persisted,
> remembered data; validating such data; naming such data; etc decidedly
> differently than other data that will hang around for less time. The
> current language does nothing to promote a holistic approach to
> software development unless you use mountain man's approach of hauling
> everything into the dbms. I think that is the next best thing to
> hauling it all out of "there" (the typical sql-dbms). (The last
> statement was for your amusement only, mostly, sortof).

I agree that this separation is a real problem for software
development.
I believe that it is a historical accident, largely driven by the
fact that dbms's have been completely dominated by commercial
interests,
while programming languages have had a much freer development path.
The problem is, indeed, that we segment these concerns (application
code and data management) but I don't believe there is actually
any contest here. The goal isn't for one side to "win." Rather, each
side has some really important lessons they have learned. The dbms
tradition is quite impoverished when it comes to writing application
code, and the application code side is really quite limited when
it comes to what they can do with data management.

I believe the solution lies in a new, higher-order view that takes
into account the lessons of both sides. That means we want the best
features of each. We need declarative integrity constraints; we
need the relational algebra, AND we need clever type systems,
polymorphism, modularity, etc. We need to have these tools all
available "right here" so they can be used together seamlessly.
The database should not feel "far away."

(As an aside, I don't think that dynamically typed languages have
a lot to offer for the enterprise. They're great for prototyping
and for quite-small teams, but they don't scale up to large
development processes. Just my opinion.)


> Ok, so you are, indeed, tapping into my brain (pretty scary). One of
> the dangers of declaring "stored" database functions as "relations" is
> that they seem so distant, as if we cannot access them. Set operators
> are fine and dandy, but people understand single transactions handily.
> They pay at the grocery store, get money from the bank, and type their
> name into ba-zillion web pages that require it. Start with individual
> "records" (as in "the doctors office keeps a paper copy of my ct scan
> record") and show that you have an API for it, then go to sets. How do
> we collect data? One record at a time. (I seem to be in a mood as if
> trying to entice Fabian to quote me, eh?)

I think this approach makes sense if we're trying to come up with
a view of programming and data management that we want to be able to
teach in high school, but I don't see why this approach is the one
we should take for the professional software engineer.

And in fact, I assert that this kind of record-at-a-time approach
is a disaster for scalability. It works fine for hundres of records,
and maybe for thousands, but for tens of thousands, or hundreds
of millions, it's a disaster. The computing landscape is distributed
now, for good or ill, and we have to build systems that don't send
a network packet for every record, or every keypress, or whatever.


Marshall

.

Relevant Pages

  • Re: Attribute-values in separate table
    ... working on data management in the ... But it's almost always an utter disaster. ... Sure it hurts to go forward. ...
    (comp.databases.theory)
  • Re: OT: SQL
    ... as part of a dbms is so spectacularly bad I am speechless. ... they are talking about in data management. ... A dbms is a *general-purpose* data management ... CPU is a general purpose computing device, ...
    (sci.logic)
  • Re: Application logic and Business logic
    ... >>multiply matrices any close to O. ... > The same as if you use a distributed DBMS with a module that is a DLL. ... No it depends solely on the facts of linear algebra. ... > Data management is, and if computerized data management is not ...
    (comp.object)
  • Re: OT: SQL
    ... as part of a dbms is so spectacularly bad I am speechless. ... they are talking about in data management. ... A dbms is a *general-purpose* data management ... CPU is a general purpose computing device, ...
    (sci.logic)
  • Re: Multiplicity, Change and MV
    ... it makes sense to separate data management from application ... our data management languages and libraries would make this ... Garbage collecting in the database (removal of functional outdated ... Compile-time constraint checks ...
    (comp.databases.theory)