>Your main speed considerations will include primarily:
>
>- size of the tables
>- type of joins, SQL statements, etc
>- indexes
>- hardware resources
>
>Work these through, and your queries should execute fine. When deciding on
>whether a table belongs in a database or not, I would consider whether it
>logically belongs with the other tables. Just because it doesn't join to
>other tables, doesn't necessarily mean it doesn't belong in the DB.
>
>An example would be a table that contains developer contact information.
TableA is pretty small at 200 megs TableB is large. TableC is a
monster. TableB and C are a combined 2500 megs and growing every day. I'm
redesigning the DB to try to eliminate a lot of the messy joins. There
will be a few inner joins. Nothing more complicated then that. Almost
everything will be joined within one of each other. No left or right
joins. TableB will be indexed throughout. This is because the info in
DB2: TableB and TableC is accessed during trading hours. Speed is a huge
concern. I can't sit there and wait for certain type of info. All the
info in TableA is run at night time during a batch process and I go over it
at 7:30AM in the morning while eating my breakfast. Speed is not a factor.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
