| Table per hierarchy | Table per subclass | Table per concrete type |
| - One table contains all types within the hierarchy.
- One type discriminate between types. |
- One table contains the base properties across the type hierarchy. - Separate table for additional properties for each sub-type. | - Table per concrete type class including inherited properties |
Showing posts with label Database Design. Show all posts
Showing posts with label Database Design. Show all posts
Wednesday, 15 April 2015
3 Common Inheritance Storage Schemas
Monday, 11 August 2014
Database diagram support objects cannot be installed because this database does not have a valid owner
TITLE: Microsoft SQL Server Management Studio
------------------------------
Database diagram support objects cannot be installed because this database does not have a valid owner. To continue, first use the Files page of the Database Properties dialog box or the ALTER AUTHORIZATION statement to set the database owner to a valid login, then add the database diagram support objects.
This error happened after an upgrade, the owner was already set as sa, so the solution was to change ownership into another login, then return it to sa.
------------------------------
Database diagram support objects cannot be installed because this database does not have a valid owner. To continue, first use the Files page of the Database Properties dialog box or the ALTER AUTHORIZATION statement to set the database owner to a valid login, then add the database diagram support objects.
This error happened after an upgrade, the owner was already set as sa, so the solution was to change ownership into another login, then return it to sa.
Thursday, 4 April 2013
Look-up tables design
1- No to a single look-up table:
a - Scalability.
b - Data Maintainability (Error prone)
2- Integrity on deletion:
a - Deletion stored procedure with the logic to restrict deletion for consumed records.
(The reason that foreign keys are not enough since typically they reside within a single DB; however, references are usually consumed from other DBs.) [My recommendation]
b- Don't delete: Just mark as deleted or add a status per record to be defined by the business.
a - Scalability.
b - Data Maintainability (Error prone)
2- Integrity on deletion:
a - Deletion stored procedure with the logic to restrict deletion for consumed records.
(The reason that foreign keys are not enough since typically they reside within a single DB; however, references are usually consumed from other DBs.) [My recommendation]
b- Don't delete: Just mark as deleted or add a status per record to be defined by the business.
Subscribe to:
Posts (Atom)
