Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.theory > #503

Re: Keeping schema static as objects are added

Show all headers | View raw

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

Back to comp.databases.theory | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Keeping schema static as objects are added sergei.sheinin@gmail.com - 2012-11-25 07:03 -0800
  Re: Keeping schema static as objects are added Eric <eric@deptj.eu> - 2012-11-25 17:19 +0000
    Re: Keeping schema static as objects are added sergei.sheinin@gmail.com - 2012-11-25 19:18 -0800
      Re: Keeping schema static as objects are added Eric <eric@deptj.eu> - 2012-11-27 20:29 +0000
        Re: Keeping schema static as objects are added sergei.sheinin@gmail.com - 2012-11-27 19:38 -0800
          Re: Keeping schema static as objects are added Arthur Ward <art.ward@noreply.xx> - 2012-11-28 08:39 +0000
            Re: Keeping schema static as objects are added sergei.sheinin@gmail.com - 2012-11-29 09:31 -0800
              Re: Keeping schema static as objects are added Arthur Ward <art.ward@noreply.xx> - 2012-11-29 18:19 +0000
  Re: Keeping schema static as objects are added Arthur Ward <art.ward@noreply.xx> - 2012-11-27 14:17 +0000
    Re: Keeping schema static as objects are added sergei.sheinin@gmail.com - 2012-11-27 08:00 -0800

csiph-web