Keeping schema static as objects are added

[sergei....@gmail.com]

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.


Thanks!

[Eric]

On 2012-11-25, sergei....@gmail.com <sergei....@gmail.com> wrote:

As posted in comp.databases.theory:

As posted in comp.databases:

> I am a developer of new programming language platform for relational
> databases. Its technology enables preventing database schema updates as
> objects are added in process of application growth and may find use in
> a range of database applications.
>
> Platform features:
> - Programming logic is updated in a database without altering its
> schema
> - Application table structures are updated in a database without
> altering its schema
> - Interpreter resides inside a database, no application software
> installation
> - Hierarchical tree structures are saved in a relational
> database and accessible by path
> - Enables updates of programming logic and data schema with
> DML SQL statements
> - Supports flow controls including variables, conditional,

> loops, function calls with in-out parameters
>

> Currently tested as a working prototype. Thanks!
> http://sprout.internetsite.eu

Anyway:

1) It would be nice to know what problem you are actually trying to
solve here.

2) Most things described as avoiding schema changes turn out to be EAV
which means, for example, that performance will not scale, and that
anything other than very simple queries tend to be very difficult to get
right.

3) You seem to have a translator and a run-time interpreter, both of
which are written in an interpreted language. This might be an
unnecessary complication.

4) You might want to reconsider the name:
http://www.cs.ox.ac.uk/projects/SPROUT/
http://cedb.asce.org/cgi/WWWdisplay.cgi?97328

Eric
--
ms fnd in a lbry

[sergei....@gmail.com]

On Monday, November 26, 2012 12:19:06 AM UTC+7, Eric wrote:
> On 2012-11-25, sergei....@gmail.com <sergei....@gmail.com> wrote:
>
>
>
> As posted in comp.databases.theory:
>

>
>
>

> Anyway:
>
>
>
> 1) It would be nice to know what problem you are actually trying to
>
> solve here.

As a platform that performs programming logic on application tables it may find use anywhere in database applications. For example it could be programmed to automatically generate html interface to an existing database by scanning its schema, as a tool for generation of reports, forms, etc.

Registry is another potential use for Sprout because of its functions to save/retrieve hierarchical tree structures.

>
>
>
> 2) Most things described as avoiding schema changes turn out to be EAV
>
> which means, for example, that performance will not scale, and that
>
> anything other than very simple queries tend to be very difficult to get
>
> right.
>

I am proposing an EAV schema that accommodates its own metadata entered when application is initialized and contains program code, hierarchical trees, pointers and table schema. All of which are stored in Sprout's normalized database in same physical storage with application data.

Normally EAV table schema requires metadata descriptors (according to Wiki "by a factor of at least three or more") whereas in Sprout the entire data schema contains one dozen of tables and no assumptions of what application metadata will apply.


> performance will not scale

Introduce automatic partitioning of EAV tables. Obviously it is some concern.

> other than very simple queries tend to be very difficult

Sprout has functions that allow querying with regular SQL statements.

>
>
> 3) You seem to have a translator and a run-time interpreter, both of
>
> which are written in an interpreted language. This might be an
>
> unnecessary complication.
>

In tests I did not observe any noticeable slowdown when program code is run with Sprout interpreter. Seems only few new calculations are introduced when using its native syntax vs procedural SQL.

>
>
> 4) You might want to reconsider the name:
>
> http://www.cs.ox.ac.uk/projects/SPROUT/
>
> http://cedb.asce.org/cgi/WWWdisplay.cgi?97328
>
>

It is great I didn't know these were out there. Surely the name can or will change.

>
> Eric
>
> --
>
> ms fnd in a lbry

Sergei

[Arthur Ward]

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

[sergei....@gmail.com]

> 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.
>
>

With my platform (and schema) I will generate table interfaces and forms with 1 SQL statement (no app server). Prove it that it's 1960's nonsense.


>
>
> Fuck off


so long :)

[Eric]

On 2012-11-26, sergei....@gmail.com <sergei....@gmail.com> wrote:
> On Monday, November 26, 2012 12:19:06 AM UTC+7, Eric wrote:
>> On 2012-11-25, sergei....@gmail.com <sergei....@gmail.com> wrote:

....

>> 1) It would be nice to know what problem you are actually trying to
>> solve here.
>
> As a platform that performs programming logic on application tables it
> may find use anywhere in database applications. For example it could
> be programmed to automatically generate html interface to an existing
> database by scanning its schema, as a tool for generation of reports,
> forms, etc.

But why are you writing your own platform rather than using one that
exists? What new thing are you adding? If you don't see it as way to
solve some actual problem that you have to deal with, then you had
better have something really new to offer, and I can't see it.

> Registry is another potential use for Sprout because of its functions
> to save/retrieve hierarchical tree structures.

Registry? Windows registry, LDAP, MUMPS, ... Assuming a registry has to
be hierarchical, which it doesn't.

>> 2) Most things described as avoiding schema changes turn out to be EAV
>> which means, for example, that performance will not scale, and that
>> anything other than very simple queries tend to be very difficult to get
>> right.
>
> I am proposing an EAV schema that accommodates its own metadata entered
> when application is initialized and contains program code, hierarchical
> trees, pointers and table schema. All of which are stored in Sprout's
> normalized database in same physical storage with application data.
>
> Normally EAV table schema requires metadata descriptors (according to
> Wiki "by a factor of at least three or more") whereas in Sprout the
> entire data schema contains one dozen of tables and no assumptions of
> what application metadata will apply.

I don't see that you are doing anything different from any other EAV
setup.

Actually, since someone else has told you that your are not taking a
sensible approach here (though less politely than that) and since
basically I agree with them, I think I give up.

EAV is a bad bad bad bad bad bad bad bad idea, and if your language has
no use beyond dealing with EAV, then it is at best pointless.

[sergei....@gmail.com]

> EAV is a bad bad bad bad bad bad bad bad idea, and if your language has
> no use beyond dealing with EAV, then it is at best pointless.
>
>
>
> Eric
>

EAV is used in the platform to keep hierarchical metadata and program code. Same mechanism accommodates table data as a feature and interfaces with 3NF tables.

My lesson from posting here is that I must do a better presentation of a language of higher level in respect to procedural SQL and with ability to update programming logic without affecting underlying schema. Storing app data in EAV is not what I set out to do (I did it first time one dozen years ago). Thanks everyone.

[Arthur Ward]

sergei....@gmail.com wrote:

> > EAV is a bad bad bad bad bad bad bad bad idea, and if your language has
>> no use beyond dealing with EAV, then it is at best pointless.
>>
>>
>>
>> Eric
>>
>

> My lesson from posting here is that I must do a better presentation
> of a language of higher level in respect to procedural SQL and with
> ability to update programming logic without affecting underlying
> schema.

Wrong. The lesson we're trying to give you is to learn some
basics then review the capabilities and shortcomings of existsing
products, and then propose better solutions.

Another lesson you should learn is that no one actually _wants_
yet another procedural language.

Thankfully the one thing you haven't mentioned is "object oriented".
Keep it that way.

Art

[sergei....@gmail.com]

> Thankfully the one thing you haven't mentioned is "object oriented".
>
> Keep it that way.
>
>
>
> Art

Art, the challenge I ran into with classes is persisting them in rdbms. I have no clues beyond temp tables or some weird query caching pump. Both so far seem unacceptable. Would you share your thoughts on how I can get it done, please?

[Arthur Ward]

Unless you business makes it's money managing objects you shouldn't be
"persisting" objects at all. I just looked in the yellow pages and I
didn't see anyone under the object management classification.

My guess is you don't see any difference between the state of the
members of an object, and facts about the enterprise of interest. If
you don't see the difference then I'd be doing your customers and users
a real disservice by giving you ideas for how to go on screwing up their
information so they can't exploit it.

To repeat someone eles, "your are not taking a sensible approach".

Art