Prev: event handling issues in presentation model
Next: Mixing OO and DB
From: topmind on 30 Mar 2008 05:21


Dmitry A. Kazakov wrote:
> On Sat, 29 Mar 2008 17:03:53 -0700 (PDT), topmind wrote:
>
> > Dmitry A. Kazakov wrote:
> >> On Sat, 29 Mar 2008 04:47:01 GMT, Brian Selzer wrote:
> >>
> >>> There is a table for attributes that are common to all
> >>> possible widgets, and a table for each set of attributes that are common not
> >>> to all possible widgets, but rather to a subset of all possible widgets.
> >>
> >> It is interesting to see people reinventing the wheel (class). The set of
> >> "all possible widgets having attributes T, U, V" is a class.
> >
> > With the existing implementations of RDBMS, I reluctantly have to
> > agree. However, in an ideal world, Dynamic Relational would exist so
> > that we wouldn't need to go to the dark side (OOP).
>
> The question is not how, but what.
>
> Dynamic vs. static is a secondary issue. An inability to check your design
> against some errors is not an advantage, when taken alone. You should first
> show what are you doing. Then you prove that it is necessary to go this way
> and that it is indeed statically uncheckable. Only then anybody would buy
> it dynamic.

Being statically checkable is usually overrated by the "compile
fanboys". Anyhow, I don't want to get into an compiler-vs-interpreter
fight here. If you like static checking, so be it. Nothing will
satisfy everybody.

>
> >> But that is not my point. The problem with widgets hierarchy is that there
> >> are three axes of widget relations. You were discussing only one of them
> >> attributes, which is usually directly mapped to types. This is not that big
> >> deal. More difficult are other two:
> >>
> >> 2. Visual containment. Widgets can consist of / contain other widgets.
> >
> > I'd prefer references rather than containment. This would allow say an
> > embedded panel to but "popped out" in a dedicated screen if the user
> > wanted. And have a form be windowed in another in one tab, but by
> > itself in another.
>
> I meant visual appearance. You can implement it as you with, but an edit
> entry is visually contained by the dialog. That is a requirement.
>
> > Besides, all we need is a "parentWidgetID" to have a basic hierarchy
> > with tables.
>
> That does not work as I explained in another post.

I missed it. But I have used "parent ID" to represent trees in tables
(unrelated to GUI's) and it DOES work. Don't tell me it doesn't.

>
> >> 3. Signal handing. Handlers of widget events are composed in a certain
> >> hierarchical way.
> >
> > I don't see why this has to be the case. We may want a form-level
> > handler to take precedence over a widget-specific handler in some
> > cases. The priority should be developer-alterable at run-time. Tables
> > would be much better at tracking all these priorities than a tree.
>
> Priorities is another word for hierarchy.

Or an ordered list. Anyhow, the event priorities may not and do not
always match the physical containment hierarchies. Thus, traditional
OO hierarchies are insufficient.

>
> So, you want to leave it to the developer, oh my. Could you give us a short
> sketch of how, for instance D&D events can be handled this way? You press a
> mouse button at something, then track the mouse motion, and finally process
> mouse button release... Good luck.

I've never really played D&D. Damn, I guess they'll revoke my Nerd
Card for admitting that. Note that there would be default priorities
inserted/assumed by the GUI IDE such that each individual one does not
need hand tuning, only the odder ones.

>
> > The biggest drawback of an OOP GUI system is that it is difficult to
> > make a cross-language OO framework. Each OOP language has such
> > different rules about inheritance and encapsulation such that building
> > a sharable framework is sticky. Most successful cross-language
> > frameworks tend to be declarative, and OOP is anti-declarative for the
> > most part.
>
> Ah, and that is different with SQL? Come on, SQL is incompatible with
> itself. Now imagine, there were more than just one relational language in
> use?

SQL is one of the best cross-language integration tools there has ever
been, even WITH its flaws. Only HTTP/HTML can touch it.

>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

-T-
From: Brian Selzer on 31 Mar 2008 05:20

"topmind" <topmind(a)technologist.com> wrote in message
news:a742d466-e6a9-4d13-a1ba-953567fcb3dc(a)u10g2000prn.googlegroups.com...
[big snip]

> It's a gut feeling for everyone here because it's never been tried in
> practice. We cannot really know with near certainty all the possible
> usage scenarios (query patterns) and which are more frequent. It's an
> educated WAG at best.
>

Perhaps some testing is in order.

> There's another suggestion that nobody's mentioned here that I know
> of: Add each new column to the Widgets table as needed, creating a
> "sparse" table. If we are going to allow add/change to schemas, then
> why not just add the new frippen column to the Widgets table and be
> done with it? Sparse tables are not really space hogs on most modern
> RDBMS like they were in the past. The overhead for unused (null)
> columns is small.
>

It's not about space. Separate tables can be indexed separately, permitting
the selection of better query plans. A lot of nulls, such as you would find
in a sparse table, skews the statistics for columns, making some indexes
that would otherwise appear optimal less attractive, leading to poor
performance.

The idea of a sparse table is ugly because it involves nulls.
Nulls--especially those that indicate 'there shouldn't be a value
here'--should be avoided whenever possible. If you're interested, there
have been many discussions on cdt regarding nulls. If you can wade through
the flames, you might even find some useful information.

Data has an inherent structure. Stuffing everything into one table, whether
it be an EAV table or a sparse table imposes an alien structure on the data,
introducing redundancy and complexity and usually reducing performance. A
solution that has one table per widget type also imposes a structure on the
data, one that inevitably introduces redundancy. The 'table-happy' design
that I suggested earlier does not introduce redundancy and does not require
nulls.


From: Brian Selzer on 2 Apr 2008 22:05

"topmind" <topmind(a)technologist.com> wrote in message
news:a5fa390d-025e-4708-93e0-588d573faa2d(a)u10g2000prn.googlegroups.com...
>
>
> Brian Selzer wrote:
>> "topmind" <topmind(a)technologist.com> wrote in message
>> news:a742d466-e6a9-4d13-a1ba-953567fcb3dc(a)u10g2000prn.googlegroups.com...
>> [big snip]
>>
>> > It's a gut feeling for everyone here because it's never been tried in
>> > practice. We cannot really know with near certainty all the possible
>> > usage scenarios (query patterns) and which are more frequent. It's an
>> > educated WAG at best.
>> >
>>
>> Perhaps some testing is in order.
>>
>> > There's another suggestion that nobody's mentioned here that I know
>> > of: Add each new column to the Widgets table as needed, creating a
>> > "sparse" table. If we are going to allow add/change to schemas, then
>> > why not just add the new frippen column to the Widgets table and be
>> > done with it? Sparse tables are not really space hogs on most modern
>> > RDBMS like they were in the past. The overhead for unused (null)
>> > columns is small.
>> >
>>
>> It's not about space. Separate tables can be indexed separately,
>> permitting
>> the selection of better query plans. A lot of nulls, such as you would
>> find
>> in a sparse table, skews the statistics for columns, making some indexes
>> that would otherwise appear optimal less attractive, leading to poor
>> performance.
>
> I doubt queries against sparse columns would be common. Generally
> there would first be a query involving the "widget type" and/or
> attribute type, which would greatly narrow what is being searched.
> And, depending on how the optimizer and index system is built, you
> don't need to store Nulls *in* the indexes. Think about it. There are
> a few operations where indexing nulls makes sense, but they are not
> common enough to bother in my opinion. There are other ways to get the
> same info. But, a given vendor may have seen it different. In short,
> it depends on the DB engine.
>

You're entitled to your opinion, even if it's wrong. There may not even be
a need for a "widget type" attribute.

> EAV's don't need to store nulls. You just don't include that entry. If
> a given index engine is not null-friendly, then perhaps an EAV is
> better than a sparse table as far as performance.
>

No. EAVs don't store nulls. But their structure makes creating usable
indexes extremely difficult if not impossible. That makes me question
whether performance would be better with an EAV.

>
>>
>> The idea of a sparse table is ugly because it involves nulls.
>> Nulls--especially those that indicate 'there shouldn't be a value
>> here'--should be avoided whenever possible. If you're interested, there
>> have been many discussions on cdt regarding nulls. If you can wade
>> through
>> the flames, you might even find some useful information.
>>
>> Data has an inherent structure.
>
> Sometimes its "inherent structure" does NOT fit static tables well.
> The real world is not always friendly to a given abstraction. And,
> although I am against "nulls" for strings, the concept of some kind of
> "empty" cell (zero length) is not necessarily a bad thing. (In some
> RDBMS, zero length and null are the same thing, in others they are
> not.)
>

I don't think you understand "inherent structure."

>> Stuffing everything into one table, whether
>> it be an EAV table or a sparse table imposes an alien structure on the
>> data,
>> introducing redundancy and complexity and usually reducing performance.
>> A
>> solution that has one table per widget type also imposes a structure on
>> the
>> data, one that inevitably introduces redundancy. The 'table-happy'
>> design
>> that I suggested earlier does not introduce redundancy and does not
>> require
>> nulls.
>
> Your solution does NOT reduce redundancy because the foreign key has
> to be repeated over and over again. And, empty cells don't
> necessarily reduce performance, per above. And, filling up table-space
> is ugly and not debugging-friendly. Fat table-spaces slow me down. I
> cannot speak for everybody's psychology and hand-eye-mouse-brain
> coordination, but it slows down MINE.
>

By most, foreign key references do not constitute redundancy. In direct
image systems, foreign key references are problematic because updates must
often physically cascade. But not all systems work that way. Some systems
internally use pointers instead of duplicating what is referenced so that
physical cascades are unnecessary. And don't kid yourself: empty cells
necessarily reduce performance, they just may not reduce it noticably.

> I will respect your choice because the tradeoffs are all sticky either
> way. But, I do not agree with it, nor do I agree with your performance
> criticisms and redundancy claims. They appear incorrect.
>
> -T-


From: topmind on 3 Apr 2008 01:06


Brian Selzer wrote:
> "topmind" <topmind(a)technologist.com> wrote in message
> news:a5fa390d-025e-4708-93e0-588d573faa2d(a)u10g2000prn.googlegroups.com...
> >
> >
> > Brian Selzer wrote:
> >> "topmind" <topmind(a)technologist.com> wrote in message
> >> news:a742d466-e6a9-4d13-a1ba-953567fcb3dc(a)u10g2000prn.googlegroups.com...
> >> [big snip]
> >>
> >> > It's a gut feeling for everyone here because it's never been tried in
> >> > practice. We cannot really know with near certainty all the possible
> >> > usage scenarios (query patterns) and which are more frequent. It's an
> >> > educated WAG at best.
> >> >
> >>
> >> Perhaps some testing is in order.
> >>
> >> > There's another suggestion that nobody's mentioned here that I know
> >> > of: Add each new column to the Widgets table as needed, creating a
> >> > "sparse" table. If we are going to allow add/change to schemas, then
> >> > why not just add the new frippen column to the Widgets table and be
> >> > done with it? Sparse tables are not really space hogs on most modern
> >> > RDBMS like they were in the past. The overhead for unused (null)
> >> > columns is small.
> >> >
> >>
> >> It's not about space. Separate tables can be indexed separately,
> >> permitting
> >> the selection of better query plans. A lot of nulls, such as you would
> >> find
> >> in a sparse table, skews the statistics for columns, making some indexes
> >> that would otherwise appear optimal less attractive, leading to poor
> >> performance.
> >
> > I doubt queries against sparse columns would be common. Generally
> > there would first be a query involving the "widget type" and/or
> > attribute type, which would greatly narrow what is being searched.
> > And, depending on how the optimizer and index system is built, you
> > don't need to store Nulls *in* the indexes. Think about it. There are
> > a few operations where indexing nulls makes sense, but they are not
> > common enough to bother in my opinion. There are other ways to get the
> > same info. But, a given vendor may have seen it different. In short,
> > it depends on the DB engine.
> >
>
> You're entitled to your opinion, even if it's wrong. There may not even be
> a need for a "widget type" attribute.

Perhaps "type" is not quite the right description. It would identify a
specific widget implementation, say the "button from Foo Inc.". That
can be used to look up the dictionary(s) of available attributes and
features.

>
> > EAV's don't need to store nulls. You just don't include that entry. If
> > a given index engine is not null-friendly, then perhaps an EAV is
> > better than a sparse table as far as performance.
> >
>
> No. EAVs don't store nulls. But their structure makes creating usable
> indexes extremely difficult if not impossible. That makes me question
> whether performance would be better with an EAV.

I don't see why this would be the case. Being a "skinny" table, you
can easily index every column. It is hard to out-index that.

> >> The idea of a sparse table is ugly because it involves nulls.
> >> Nulls--especially those that indicate 'there shouldn't be a value
> >> here'--should be avoided whenever possible. If you're interested, there
> >> have been many discussions on cdt regarding nulls. If you can wade
> >> through
> >> the flames, you might even find some useful information.
> >>
> >> Data has an inherent structure.
> >
> > Sometimes its "inherent structure" does NOT fit static tables well.
> > The real world is not always friendly to a given abstraction. And,
> > although I am against "nulls" for strings, the concept of some kind of
> > "empty" cell (zero length) is not necessarily a bad thing. (In some
> > RDBMS, zero length and null are the same thing, in others they are
> > not.)
> >
>
> I don't think you understand "inherent structure."

I suspect you have a personal pet concept that you gave that label.
But you're free to prove me wrong. "Structure" is usually a human-
built abstract model to approximate or describe some limited aspect of
the real world, and there are many possible ways to model the same
given thing.

> >> Stuffing everything into one table, whether
> >> it be an EAV table or a sparse table imposes an alien structure on the
> >> data,
> >> introducing redundancy and complexity and usually reducing performance.
> >> A
> >> solution that has one table per widget type also imposes a structure on
> >> the
> >> data, one that inevitably introduces redundancy. The 'table-happy'
> >> design
> >> that I suggested earlier does not introduce redundancy and does not
> >> require
> >> nulls.
> >
> > Your solution does NOT reduce redundancy because the foreign key has
> > to be repeated over and over again. And, empty cells don't
> > necessarily reduce performance, per above. And, filling up table-space
> > is ugly and not debugging-friendly. Fat table-spaces slow me down. I
> > cannot speak for everybody's psychology and hand-eye-mouse-brain
> > coordination, but it slows down MINE.
> >
>
> By most, foreign key references do not constitute redundancy.

I disagree. For one, it fills up the schemas with duplication
regardless of what is actually in the tables. Human eyes have to sift
over all that.

> In direct
> image systems, foreign key references are problematic because updates must
> often physically cascade. But not all systems work that way. Some systems
> internally use pointers instead of duplicating what is referenced so that
> physical cascades are unnecessary. And don't kid yourself: empty cells
> necessarily reduce performance, they just may not reduce it noticably.

I would bet that joins slow things down more than empty cells. But we
can agree to treat it as a wash for this debate.

>
> > I will respect your choice because the tradeoffs are all sticky either
> > way. But, I do not agree with it, nor do I agree with your performance
> > criticisms and redundancy claims. They appear incorrect.
> >

-T-


First  |  Prev  | 
Pages: 1 2 3 4
Prev: event handling issues in presentation model
Next: Mixing OO and DB