Re: Abbreviation List Tables Design, aka OTLT


Simon Verona wrote:
> I understand the theory of not worrying

I like that theory of not worrying. Thanks for bringing it to my
attention ;-)

> 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..

I'm all in favor of excellence in data modeling throughout the process
of developing software, including database design, but agree that doing
so in a vacuum is not good.

> To me, it seems logical to think of the likely ways that data will be used
> and incorporating that into your database design methodology!

I definitely agree. I'm looking for where MV folks "naturally" do
things that are skewed from an industry perspective of what should be
best practices. MV best practices align more with common sense than
with theory. That would be the same tool used by "secretaries" for
years when doing data and file management. But there is no obvious
mathematical theory being implemented with that approach ensuring that
we will be safe from update anomalies, for example.

> A few more euros your way!

Danke. --dawn

> Simon
> "dawn" <dawnwolthuis@xxxxxxxxx> wrote in message
> news:1138208528.975765.160770@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > Simon Verona wrote:
> >> Well, the problem for me is size of the record... MV is still not very
> >> good at churning large records around in memory.... Hence why I make the
> >> differentiation between large and small lookup lists. I don't mind
> >> reading
> >> in a lookup list of 100 in one read, but for 1000 it wouldn't be so
> >> practical.
> >>
> >> By the same token, you are unlikely to use a drop-down lookup for 1000
> >> items
> >> whereby you might for 100... For 1000, you would ask for a code and
> >> then
> >> validate it (this is where the STATES*XX lookup is more efficient as you
> >> still only need one disk read to validate but you have no requirement for
> >> the whole lookup table at once.)
> >>
> >> Not sure how to state that mathematically though! The key thing in my
> >> mind
> >> is whether you'd ever need the whole lookup table at once in your
> >> application. Drop-down list boxes is the key scenario where you would
> >> have
> >> this.
> >>
> >> Hope I'm making some sense!
> >
> > Yes -- that gave me some good insight into the rationale for various
> > approaches. While it is (typically) considered very bad database
> > design to think about the UI when modeling the data, that is what often
> > is done (for better or worse, I don't have an opinion on that yet).
> > So, you might put all lookup lists that might end up as drop-downs into
> > a single file, reusing all of the same code no matter which lookup list
> > is needed and then for larger lookup lists, put them in separate files
> > and use different reusable components for those.
> >
> > Such an approach seems effective, maintainable, usable, and considered
> > poor design in theory because you have coupled your database design in
> > some small way to your UI design. Vewy intewesting. thanks. --dawn
> >

.

Relevant Pages

  • Re: problem using identity column as primary key
    ... > is still identified and a Unique constraint is ... If you don't have a natural key, you have exactly the thing that Joe ... Pro SQL Server 2000 Database Design ...
    (microsoft.public.sqlserver.programming)
  • Re: Abbreviation List Tables Design, aka OTLT
    ... Too much time is spent on designing the database, ... >> differentiation between large and small lookup lists. ... Drop-down list boxes is the key scenario where you would ... > design to think about the UI when modeling the data, ...
    (comp.databases.pick)
  • RE: How to build a successful database for Sales
    ... You are sort of at the general starting point of a database design which is ... Then design a table structure to implement what you clarified / decided. ... Then create 2 links from the junction table record to the other 2 ...
    (microsoft.public.access.tablesdbdesign)
  • Re: census database design
    ... The database design, mean the table ... > table names and field names (age groups). ... > so if, in 2004, one county district had a count of people for each of five ... > the ironclad rule of database design is: ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Database Design Problem
    ... The problem I have with putting the Product Catagory in ... > Design is a hard thing to do if you want a good design that is. ... There are lots of normalization rules ... Database Design is very difficult for me because I do ...
    (microsoft.public.sqlserver.programming)