Re: Abbreviation List Tables Design, aka OTLT

On Wed, 25 Jan 2006 21:29:01 -0000, "Simon Verona" <nomail@xxxxxxxxxx>
wrote:

>I understand the theory of not worrying about the user when designing your
>database, but imho it's this that causes many development projects to run
>over time and budget... Too much time is spent on designing the database,
>which is inflexible and slow when building the application..
>
>To me, it seems logical to think of the likely ways that data will be used
>and incorporating that into your database design methodology!

Wholeheartedly agree. And this has been nagging at me since the
beginning of the thread.... Start with ALL of the requirements of
ALL of the users and work "back" from there....

When you've got ALL of the requirements THEN look at what is needed
and how best to incorporate it ALL into one useable environment, be it
files, be it look-up records, be it punch cards, be it yellow
"stickies" on the side of the terminal, be it whatever.

Don't strangle the thing with "methodology" before it's born.

And don't forget, for the same "look up table" one user might have 3
items and only want "descriptive reference", another user might have
100 items, and "absolutley need" some "transactional" data related to
the items to be maintained......

Horses for courses.

>
>A few more euros your way!

And what's a little Aussie marsupial got to do with it? ~8^))

Although, today is "Australia Day"......

>
>Simon
Regards,

Bruce Nichol
Talon Computer Services
ALBURY NSW Australia

http://www.taloncs.com.au

If it ain't broke, fix it until it is....
.

Relevant Pages

  • Re: Relational database & OO
    ... The RDB Data Model and the solution's Class Model will typically be different for non-CRUD/USER applications because they need to be optimized differently. ... all the business systems I've participated coding or designing spent little production time changing data. ... Given statistics like these it makes little sense to design your application or OO model before designing your database. ... And OO Class Models are routinely normalized as part of the basic paradigm methodology. ...
    (comp.object)
  • Re: Writing a DAL with TDD
    ... will use the database - which is what you advocated elsewhere. ... designing some new algorithm for a particular business scenario. ... you'll say that we "just" mock those things... ... talented developers, coupled with the strongest ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Writing a DAL with TDD
    ... will use the database - which is what you advocated elsewhere. ... designing some new algorithm for a particular business scenario. ... you'll say that we "just" mock those things... ... talented developers, coupled with the strongest ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: relationship vss join
    ... A AAZ ... B BCJ ... into the database initially, nor one on which referential integrity could be ... In the process of designing a database, ...
    (microsoft.public.access.queries)
  • Re: Writing a DAL with TDD
    ... naive to drive a database design from the point of view of the code that will use the database - which is what you advocated elsewhere. ... The benefits of TDD seem readily apparent - to me anyway - when applied to things like developing an application framework or parsing engine, or designing some new algorithm for a particular business scenario. ... or ASP.NET Web application, where a lot of code MUST interact with external systems or be dependent on things like ASP.NET Application state, Session state, or the HTTP request pipeline, then we're forced to make our unit tests depend on external things like the HTTP request pipeline or an external database. ... Let me see you mock the HTTP Request pipeline and unit test some code that overrides ASP.NET's Application.Init method. ...
    (microsoft.public.dotnet.languages.csharp)