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

We are not here to do your schoolwork for you.

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

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.