Re: Keeping schema static as objects are added

On 2012-11-26, sergei.sheinin_at_gmail.com <sergei.sheinin_at_gmail.com> wrote:
> On Monday, November 26, 2012 12:19:06 AM UTC+7, Eric wrote:
>> On 2012-11-25, sergei.sheinin_at_gmail.com <sergei.sheinin_at_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.

Eric

-- 
ms fnd in a lbry