Re: Keeping schema static as objects are added

sergei.sheinin_at_gmail.com wrote:

> I am developing a platform for relational databases that keeps
> schema unchanged as programming logic or table structures change. It
> is made of a storage with fixed data schema containing several
> tables and a set of functions all of which are written with
> procedural SQL.

> The functions enable interface to modules that save and retrieve
> data and execute programs in an interpreter. Updates of program
> logic and table structures are done with DML. Tables are queried by
> calling a table function and may contain columns of different
> datatypes. Program logic is executed by calling the interpreter with
> tree path of called function. Programs are made of commands mapped
> to a block of procedural SQL and support program flow controls
> (variables, conditional, loops, function calls with in-out
> parameters).

> The storage enables saving tree structures in relational database.
> It may accommodate any number of configuration settings for database
> objects as well as keep table data.

Sergei, there is no gentle way to say this that won't give you the idea that maybe, if you work on it just a little harder, there is hope for this idea. SO I'm just going to come out and put it plainly: you are either a fucking imbecile or fucking lazy. Or both.

Your bone-head scheme has been imagined and re-imagined many times before, and if you've not taken the time to look into it then you are at least lazy.

Before you go off devising your own "metadata" take a few minutes to find the metadata that even a piss-poor SQL DBMS can give you. Then invest a few more hours learning how a logical model captures a formal expression of the conceptual model. Then ask yourself what you could possibly add to that, because that's where we really run out of steam.

You seem to be another of those fucking programmers who don't want to learn the database theory we already have, and who thinks the ease with which we can shape even an SQL database is the problem! I cannot count the times (it must be into the thousands) that I have heard programmers say this or that SQL DBMS is too inflexible and then without skipping a beat they describe all the code changes they have to make because someone used one ALTER TABLE to add a column, or two CREATE TABLE AS SELECT statements to decompose a table. Even SQL, as shit as it is, is unimaginably more advanced than your 1960s era nonsense.

Maybe you're a nice guy, but if you think you can come here and explain to us all that we got it horribly wrong and EAV is the answer, you're going to get your ass handed to you.

Fuck off and do some reading before you try lecturing your betters again.

Art Received on Tue Nov 27 2012 - 15:17:43 CET