Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.ms-sqlserver    |    Notorious Rube Goldberg contraption    |    19,505 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 17,733 of 19,505    |
|    Erland Sommarskog to Iain Sharp    |
|    Re: Avoiding the dreaded metadata.    |
|    18 Jan 10 22:47:40    |
      XPost: microsoft.public.sqlserver.programming       From: esquel@sommarskog.se              Iain Sharp (iains@pciltd.co.uk) writes:       > So, I have a series of tables with different columns (but some       > 'common')       >       > e.g.       > Sales order items (oritem)       > Process order stock requirements (orstkall)       > Picking note items (pickitm)       > Miscellaneous manual stock reservation (       >       > Each table can provide a requirement for stock based on status of       > item. I therefore have another table (allocation) which contains the       > outstanding requirements for stock, from which I need to create a       > relation back to each of these tables. Allocations for a particular       > row in any of these tables are stripped and rebuilt frequently.       >       > Each of these has a primary key of the same type (int)       >       > A cutdown of allocation is shown below       >       > This is causing us issues with software like crystal reports, where       > one cannot include the metadata in the link without effort, and thus       > 'spurious' links are arising.       >       > So, 1. would you strip the metadata from this table? and 2. How would       > you approach removing the metadata from this table?              If I understand this correctly, there is a a column in this allocation       table that specified which table the row refers to.              That is rarely a good design, and tend to cause problem. Really what       you should do is difficult to tell with so little information about       the full picture. And then cryptic column names do not help.              Am I right to understand that all these orstkall, picktim etc share a       common ID space?              My reflection is that either all these tables reflects distinct entities,       in which case there should be one allocation table per entity. Or       they are in fact all the same entity, or subtypes of one, in which case       there should be a common table which also owns the ID.              But as I said, with so little information it's very difficult to come       with design suggestions.              --       Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se              Links for SQL Server Books Online:       SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx       SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx       SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca