Click here to Skip to main content
15,920,438 members
Home / Discussions / Database
   

Database

 
QuestionOracle tables and columns by SQL Query Pin
PasNad12-Oct-06 19:28
PasNad12-Oct-06 19:28 
AnswerRe: Oracle tables and columns by SQL Query Pin
rah_sin13-Oct-06 0:16
professionalrah_sin13-Oct-06 0:16 
GeneralRe: Oracle tables and columns by SQL Query Pin
PasNad13-Oct-06 17:10
PasNad13-Oct-06 17:10 
GeneralRe: Oracle tables and columns by SQL Query Pin
rah_sin15-Oct-06 17:55
professionalrah_sin15-Oct-06 17:55 
AnswerRe: Oracle tables and columns by SQL Query Pin
Akhilesh Yadav15-Oct-06 23:46
Akhilesh Yadav15-Oct-06 23:46 
GeneralRe: Oracle tables and columns by SQL Query Pin
simplemusings17-Oct-06 3:55
simplemusings17-Oct-06 3:55 
QuestionDatabase best practice - large tables. Pin
MY120112-Oct-06 3:28
MY120112-Oct-06 3:28 
AnswerRe: Database best practice - large tables. Pin
Colin Angus Mackay12-Oct-06 3:43
Colin Angus Mackay12-Oct-06 3:43 
Bad Robot wrote:
Would it be better to split the table into smaller tables?


Does the data suggest you should do that?

Bad Robot wrote:
Consider a factory. The factory pollutes. In order to keep track of the pollution, the factory owner has to fill in some 20 values of different kinds. Normally you would place these values on the factory table, but since there are so many of them, you might be able to put the pollution data in another table called PollutionData. But somehow I can't get this to work properbly. I have the factory referencing the PollutionId in the PollutionData table.


Is your polution data of the kind like:
COPollution1
CO2Pollution1
SO2Pollution1
COPollution2
CO2Pollution2
SO2Pollution2 etc.

If so then that is an obvious candidate for a one-to-many join as there are repeating fields (with an index marker in the name)

If you have 20 non-repeating columns, are they (as a block) optional? In otherwords: Can a factory exist without these values?

From what you've said already, regardless of the details of how the data relates, it is obvious that the Factory is the parent. A factory pollutes, without the factory you don't need the pollution data. Therefore, the PollutionData should reference the Factory table. The PollutionData table should have a FactoryId column.

Bad Robot wrote:
A cascade delete will only work the other way around!


Well, put it the other way around. From your description, it seems that is the correct way to go.

Bad Robot wrote:
And I want the database server to produce an error if someone tries to delete pollution data referenced by a factory.


Difficult one this. If you forbid this, then you cannot delete a factory either. I'd say you enforce this by using only stored procedures to access your data. The stored procs can enforce that rule.


Bad Robot wrote:
As I see it - the only way to solve this is to put the pollution columns into the Factories table, but I have this kind "oh noes - this is wrong"-feeling - and that's just because there are so many columns.


If there are no repeating columns, and the data must always exist with a factory then it is not wrong. You can have upto 1024 columns in a table in SQL Server. The limit is that high because there are valid reasons to have that many columns.

Does this help?


GeneralRe: Database best practice - large tables. Pin
MY120112-Oct-06 6:04
MY120112-Oct-06 6:04 
GeneralRe: Database best practice - large tables. Pin
Colin Angus Mackay12-Oct-06 7:13
Colin Angus Mackay12-Oct-06 7:13 
AnswerRe: Database best practice - large tables. Pin
Eric Dahlvang12-Oct-06 4:22
Eric Dahlvang12-Oct-06 4:22 
GeneralRe: Database best practice - large tables. Pin
MY120112-Oct-06 6:10
MY120112-Oct-06 6:10 
GeneralRe: Database best practice - large tables. [modified] Pin
Eric Dahlvang12-Oct-06 6:51
Eric Dahlvang12-Oct-06 6:51 
GeneralRe: Database best practice - large tables. Pin
Colin Angus Mackay12-Oct-06 7:14
Colin Angus Mackay12-Oct-06 7:14 
GeneralRe: Database best practice - large tables. Pin
MY120112-Oct-06 7:33
MY120112-Oct-06 7:33 
GeneralRe: Database best practice - large tables. Pin
Colin Angus Mackay12-Oct-06 11:21
Colin Angus Mackay12-Oct-06 11:21 
GeneralRe: Database best practice - large tables. Pin
Eric Dahlvang12-Oct-06 8:03
Eric Dahlvang12-Oct-06 8:03 
GeneralRe: Database best practice - large tables. Pin
MY120112-Oct-06 8:36
MY120112-Oct-06 8:36 
AnswerRe: Database best practice - large tables. Pin
Akhilesh Yadav15-Oct-06 23:53
Akhilesh Yadav15-Oct-06 23:53 
Questionnavigation bar Pin
m.m._200712-Oct-06 1:36
m.m._200712-Oct-06 1:36 
AnswerRe: navigation bar Pin
Colin Angus Mackay12-Oct-06 2:40
Colin Angus Mackay12-Oct-06 2:40 
Questionget value from Gridview Pin
sbao00411-Oct-06 23:32
sbao00411-Oct-06 23:32 
AnswerRe: get value from Gridview Pin
Jay_se12-Oct-06 1:11
Jay_se12-Oct-06 1:11 
GeneralRe: get value from Gridview Pin
sbao00412-Oct-06 2:29
sbao00412-Oct-06 2:29 
GeneralRe: get value from Gridview Pin
Jay_se12-Oct-06 21:26
Jay_se12-Oct-06 21:26 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.