Re: satisfies algorithm

On 26 juil, 19:40, "David Portas"
<REMOVE_BEFORE_REPLYING_dpor..._at_acm.org> wrote:
> "Brian Selzer" <br..._at_selzer-software.com> wrote in message
>
> news:PoFik.34002$ZE5.2132_at_nlpi061.nbdc.sbc.com...
>
>
>
>
>
> > "David Portas" <REMOVE_BEFORE_REPLYING_dpor..._at_acm.org> wrote in message
> >news:vJ6dnRSku8yechfVnZ2dneKdnZydnZ2d_at_giganews.com...
> >> "Brian Selzer" <br..._at_selzer-software.com> wrote in message
> >>news:92kik.14667$cW3.1512_at_nlpi064.nbdc.sbc.com...
>
> >>> Yes. Normalize. A schema that is in BCNF does not have any nontrivial
> >>> functional dependencies where the determinant is not also a key. Where
> >>> there is a key, there should also be a unique index of some sort, making
> >>> it impossible for there to be two tuples with the same determinant.
>
> >> Unique indexes have nothing to do with keys. A key is a logical construct
> >> whereas an index is merely one possible physical structure used by some
> >> DBMSs. A key does not require an index.
>
> > Keys have the uniqueness property. Don't you agree that the uniqueness
> > property should be enforced by whatever implementation is chosen?
>
> Yes of course.
>
> > I think you would be hard pressed with today's technology to find a more
> > efficient implementation method to enforce the uniqueness property than
> > maintaining an index--especially when a relation has more than one key.
>
> This is a different thing from saying there "should" be a unique index for a
> key. Some DBMSs don't even have the concept of indexes (Netezza comes to
> mind). Whether a database has indexes or not has nothing to do with whether
> keys are enforced.
I confirm. The era of SQL dbms's is coming to an end as they simply can not cope anymore with the incredible amount of *physical* duplicate data and their unability to perform low level ra operations.

Newcomers and old niche market actors using different physical encoding schemes than direct image encoding becoming more industry relevant via the buzz of datawarehousing and business intelligence: Netezza, Cognitio, Sand Technology, DataAllegro (which was recently purchased by Microsoft for the next version of SQL Server)...The success of these actors demonstrate the limits and fragility of the current SQL based systems by obtaining success only by obtaining the better response times.

As for myself, I developped a new encoding scheme and computing model that totally takes away the need for indexes. The model by optimizes ra operations at physical level in a way I have not observed before. The subsequent developped db core shows promising results and allows to perform operations that would be simply IO unthinkable on a direct image system: After all, on relations representations that contain 2billion tuples and more, I obtain lower response times on a 7200rpm dual core cpu desktop than on an 15000 rpm octo core monster loaded with Oracle and/or SQL Server without the need for a single index.

Indexes are indeed the direct consequence of industry lazyness to implement computing models that support adequately ra operations and *not* consequences of the RM itself which is a different layer. I would go even further as saying that any direct image system can *not* be a trdbms, ever since it has fundamental limitations that increase as the number of tuples represented increases.

Finally the experience of building the model confirmed that a TRDBMS can simply not exist unless the following equation is finally resolved:

TRDBMS = RM + RA Computing model + RA optimized encoding scheme + RA manipulation/definition language

IMHO. Regards Received on Sun Jul 27 2008 - 01:28:49 CEST