Registered: Oct, 2005
Re: Software Development Has Stalled
Posted: Feb 11, 2010 2:58 AM
> > > > I am still playing around to find alternatives.
> > >
> > > Have you yet read and understood Date, Darwen,
> > McGoveran?
> > >
> > So I'd like to think I understood enough.
> > What is missing in my opinion is that the access
> > should be REST like, using HTTP and JSON.
> Again, the view of a coder, not a data geek. Both Codd
> and Date offered up relational sub-languages; what we got
> was SQL, better than nothing. The notion that data can
> sit in an uncontrolled lump to be poked at by various and
> sundry "clients" is what's led to the Babel we have. The
> datastore has to be the point of control, otherwise it's
> just files, and of no additional value; MySql became
> popular just because coders were too lazy to write I/O
> routines and so used its primitive SQL syntax to move data
> in and out of files while ignoring any relational
It did the job for them and is better accessible than blackboxed binary repositories the 'serialisation' people are so fond off.
What Codd/Date did not have are Schema browsers with Excel like datagrids, URLs and favorites.
Using Toad, SqlDeveloper end users, not data or code geeks can access data and see what is going on.
Although this does not change anything theoretically it makes the data much more accessible, so they can point out errors in business logic (or in the data itself) without having to consult some guru.
> If you want webservers (REST, HTTP, JSON, etc.) to taken
> on datastore control functions (IBM would love you for a
> client), good luck. It's not as easy as you think. Some
> very smart people, a few of which I've known, have been
> grappling with implementing Dr. Codd's model for nearly 40
> years. SQL databases are still not fully relational.
I can live with SQL as JSON over HTTP. 3rd normal form is not my goal, but getting things done without too much regret in 3 years...
> Part of the reason is that coders still insist on looping
> g through records in application code (see here:
> t-sql-set-based-speed-phreakery/ for an object lesson), so
> the vendors haven't been willing to make the effort to
> educate and build a truly relational data language;
Sometimes pure relational wins, sometimes a PL/SQL loop gets the job done easier. It's like XML fanboys saying everything is a tree, where a lot of problems are happy with table solutions.
> Chamberlin's SQL isn't. Part of the reason is that set
> operations are inherently parallel, and until recently,
> parallel operations in hardware were not widely feasible.
> Today, they are. Add SSD storage, and BCNF datastores
> s are a piece of cake, if you want.
> Shared, disciplined data is the point of the relational
> database (and to a lesser extent, its predecessors); this
> is what Codd and Date, et al, have built. Coders
> generally want to be able to scribble willy-nilly in the
> data lump without concern for others. Again, doing so is
> the main cause of the Data Babel.
Our coders like the data as a relatively stable centre of the application. So different readers/writers/views acces the data and make migration of code and schema relatively painless.
> You can't have it both ways: either Data Babel with each
> client program poking at some files with no concern for
> others, or a shared disciplined datastore. If the latter,
> then the database engine has control of update. That puts
> control in the hands of data geeks, not coders, leaving
> coders to display and accept user input.
I have absolutely no problems with isolating data access / queries from the code and accept optimization changes from DBA's. Truth is, we should cooperate: Data geek, Business logic geek, Code geek and GUI geek. We should partition our mostly declarative JSON so that these professions can work together but also mostly individual.
> There are lots of multi-database editors; on windoze my
> fave is AQT. If you're talking to a real database, you
> will need a compliant client; that can't be avoided.
> ODBC/JDBC provide a large common set of functions.
I want JSON, HTTP an Webbrowser and an ExtJS grid.
So I can play with/browse data, queries and views and then copy/paste them in the business logic in a way that DBA and frontend can see what is going on and optimize/analyse their part.
> > RDBMS is nice for table like JSON data. Not for files,
> > blobs or deep trees. So MongoDB, CouchDB and QT QML are
> > other things to play with...
> Every industrial strength database has the capability to
> reference/link external files and blobs, if you want.
> With CTE (SQL2), trees are not an issue, unless you're on
> n Oracle, I believe you're still are limited to CONNECT BY.
Well the capability is there, but blobs suck because the may not have structure from an RDMBS point of view, but they do have from an application point of view (mp3 tags, jpeg exif tags). RDBMS (and JSON/HTTP) are not appropriate for video, music and photo's. Here I like Azures seperate Blob store more than the local RDBMS approach