You could add a UserId column to Customer and still use it for querying purposes. For instance, let's say you have a Customer table with its own ID column, and you have a User table with its own ID as well. You could instead configure two tables such that one refers to the other, but without any defined foreign key. You don't have to configure a foreign key constraint on a column just because it refers to another column. However, you should understand that it is not the only way. There are many advantages to using this approach and this article is not in any way trying to talk you out of using this approach as your default, go-to way to model data in your systems. If you've ever gotten an error trying to delete a row in a table telling you it would violate a foreign key constraint, you've experienced this firsthand. Referential integrity is enforced by the database engine itself, ensuring that certain constraints are enforced, such as not allowing an orphaned foreign key (a key with a value that doesn't exist in the related table's specified key column). Many developers are quite familiar with how to model data using referential database concepts, including primary and foreign keys and associated relationships. Some of them can be bent, others can be broken." - Morpheus "What you must learn is that these rules are no different than rules of a computer system. This whole idea came as a bit of a shock to the developer in question, who had learned "the rules" of data, of which referential integrity and key relationships were near the top. There are other ways to model data, and they involve tradeoffs. This inspired a separate thread about how to decouple related concepts in a system, and the idea that you don't have to use foreign keys and third normal form for every data model. The sheer number of many-to-many and one-to-many relationships along with recursive and optional relationships made the whole design difficult to approach and begin, much less complete. One of the members was trying to work out a fairly complex design involving many different parts, and the idea of trying to model all of this as a set of database tables with primary key and foreign key relationships was daunting. A recent discussion on the private server spurred this article.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |