Results 1 to 4 of 4

Thread: DBMS Models

  1. #1
    Join Date
    May 2008
    Posts
    2

    DBMS Models

    Hello,

    I'm trying to build up a comparision of database models. I've started with the table below and would really appreciate any further input to make it more comprehensive. I'm struggling abit on the OO type:

    Hierarchal
    Performance: High speed access
    Structure: Simple to design, however relationship can only exist vertically and not horizontally
    Size:
    Database independence: Good
    Problems:


    Relational
    Performance:
    Structure: Comprises of 3 things (1) Tables, (2) Operations that act on table, (3) Rules
    Size:
    Database independence: Requires relational capable software such as Oracle
    Problems:


    Object Orientated
    Performance:
    Structure:
    Size:
    Database independence: Requires relational capable software such as Oracle
    Problems:


    Network
    Performance: Better than hierarchal
    Structure: Resembles a lattice structure. Allows multiple child and parent records
    Size:
    Database independence: Good
    Problems: Lack of structural independence

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    We are not here to do your schoolwork for you.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  3. #3
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    You've made a reasonable start; but I would go in to more depth with what you've got so far.

    For example; WHY is a heirachial model good for high speed access?

    I find it interesting how you have to comment on size in a day in age when memory is so cheap.

    And the answer "good" will not get you any marks - one again you're laying the answers thin on the ground - pack them out with detail so you can show you actually know if or why it is "good".
    George
    Home | Blog

  4. #4
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    For speed, I've always used the concept that the less tables you have to link into a query on an indexed table, the faster your results. You pay a speed price for each table you link into a query and for me the question would be, do I store the field in the main table (making it flatter, faster and more flexible for grouping) versus relational and slower returns linking in 1 or more tables to get the values. Obviously though you don't want a completely flat table without relational ones. Just flat on the commonly used fields you group on. I may end up duplicating data in the relational table (for quick returns on the fewer fields in the relational table) but for putting together many grouping combinations, I index and include those grouping fields in the main table which gives me 1 table with many options to total on (similar to a summary table). There is a balance on doing this and you have to determine the right combination of fields to include in the main table but correct me if I'm wrong that every linked table in a query is slower than if that field where in the main table and you didn't need to use the linked table.

    In my situation, I needed to often group and total on a multitude of fields (which also had relational tables holding those values as well). It may not be the "correct" technique but I could produce very fast results from dozens of combinations of fields on quite a few million records. Of course, correct indexing always plays a big factor.
    Last edited by pkstormy; 05-30-08 at 00:10.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •