SQL Databases Poll

[duniyadnd]

Just curious, how many databases do you guys generally keep per site of yours, how many tables per database and how many entries per database. I know the answers can be very broad (one table could have maybe 10 entries and another could have over 10,000), but just trying to get an understanding of what is too much information in the database.

Duniyadnd

[raf]

to get an understanding of what is too much information in the database.
Well, for me, that has nothing to do with the number of records, but has everything to do with the way you organised the data. I mean, a db that contains a few tables of a few hundred records each, can contain 'to much information', that is unessecary variabels or values that occur more then necessary. I think that in a good designed db, the tables actually don't contain information as such, buth more contain data and that the data is 'transferred' into information by the business logic of your app. (don't take this to literally, it's more the idea that counts)
Also, 'what is to much information' depends on your app and the requirements of it. If it needs to have fast response times, and especially if you work on 'static' tables (containing historical data ect), then you'll probaly have some data overspill. Joins take time, agregating takes time, calculating takes time etc, so your db will contain unnessecery data to improve the responsetime.
So for most apps, size is not the main concern. A good db-design and configuration that is optimized for the critical processes of your app + that can handle a fair number of simultanious users with reasonable response times, is far more important. (i believe even an access db can handle hundreds of thousands of records, but it'll probably collaps if a few simultanious users work an it then)

Most OLAP tools (online analytical processing) on huge tables/db now have some sort of MDDB (multi dimensional db) which contains values for all relevant combinations of all values from the included variables. So you could think of it as huge flatfiles with millions of records and the same number of variabels as dimensions. All posible selects or precomputed there (which makes the size of the db's explode) but selecting on one big (huge) table that contais all info goes faster then starting to query tables and agregating values.
The biggest db at work contains about 340 milions of record. Which is about 50 GB. So that is realy to much to query in an end user app. But the db's for our front application sometimes contain a few million of records with very reasonable response times.

Quantity is not the issue. The design more depends on the requirements of your app and the 'nature' of the data.