Re: Any new thoughts on OTLT (One True Lookup Table)

From: ben brugman <ben_at_niethier.nl>
Date: Mon, 29 Mar 2004 12:08:06 +0200
Message-ID: <4067f586$0$6566$4d4ebb8e_at_read.news.nl.uu.net>


"Leandro Guimarães Faria Corsetti Dutra" <leandro_at_dutra.fastmail.fm> wrote in message news:pan.2004.03.28.20.27.27.821100_at_dutra.fastmail.fm...
> Em Mon, 08 Mar 2004 17:02:09 +0100, ben brugman escreveu:
>
> > Having a single or limited number of tables and more codes, makes your
> > code reusable without altering the database
>
> And makes your DB unusable without deep code knowledge...
>
Most databases are only usable, because we have context, be it the real world, coding or other. A database using names from a 'strange' language (so no language context) can not be understood by a 'normal' human being. The context is needed.

And there are loads of databases designed to hold information and codes, where the codes and the codetypes where not available on design time. For example a shop (often a webshop) runs on a database with an application where the database and application (and the programmers behind it) where at design time not familiar with the product, their attributes and the codes. Specifically because at design time it was stated that the shop's database must be able to hold information about products which did not exist at design time.

Say the mobiele phones where not know at design time. But the database has to hold information about the phones. Offcourse things like size, weight and prize are 'general', but also a code is needed for a large or small sim card, a code is needed for the system the mobiele phone works on, a code is needed for the size group the phone falls in. Later on codes are needed for the type of photographs the mobiel can hold and take. (So some attributes have to be added later on to a product.)

It is assumed by me that the tables are designed at design time, and therefore can not be altered once the application is running. Therefore you need a 'general' system to hold your products their attributes and the codes for the attributes.

A good design will solve the above requirements, but then you need some generalised 'product/attribute/value/code' system. The code needs offcourse to be aware of this system, but it does not need the deep knowledge about the codes (Not in existence yet).

A design where each code has it's own table is not feasable and 'rebuilding' the application everytime a new codetype is introduced, would make the solution economically unfeasable.

ben brugman

>
> --
> Leandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219
> Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607
> 04.674-000 São Paulo, SP BRASIL
> http://br.geocities.com./lgcdutra/
Received on Mon Mar 29 2004 - 12:08:06 CEST

Original text of this message