- 6/12/2017 4:09:46 PM
Well, I've been familiar with your advocacy for some years now -- it's appreciated.
I'm fortunate enough to work in a sort of old-school environment where no one questions that the designs for our OLTP applications should be based on solid RDBMS conventions. I feel lucky not to have to explain to upper management why we haven't converted our ASE implementations to some flavor of NoSQL by now.
Thanks for your responses.
- 6/12/2017 3:16:58 PM
Incidentally a PK is a combination of one or more attributes that satisfies a PK constraint--uniqueness--in the relation--so "keys vs. constraints" is a rather misleading phrase.
- 6/12/2017 3:13:23 PM
That type of statements in an industry characterized by a lack of and disregard for foundation knowledge reinforces confusion and misconceptions.
Constraints are not relevant for read-only databases, provided of course that the data originates in a database that DID enforce all the necessary constraints. That cannot be expected with current products and practices, but then applying constraints in the replicate stage is too late.
- 6/12/2017 11:55:45 AM
Sorry for any confusion, but I was simply making a comment about the quotation you included and were responding to in your original post. I wasn't indicating agreement with the quotation and certainly understand referential integrity and its importance.
Occasionally the distinction between using a FK column as the basis for a join and actually defining the constraint comes up. For example, I have found that defining constraints in a read only replicate can degrade replication performance considerably, so typically I create such replicates without the FK constraints required in the primary.
- 6/1/2017 4:56:08 PM
That's simply wrong.
Constraints represent in the database the meaning of the reality that the database represents. Without the constraints you can enter arbitrary random data in the database and render it meaningless.
One of the core objectives of database management is to make constraint enforcement a database function and take it away from applications. If you don't know why that is crucial, may I suggest some education of data fundamentals.
If you don't have the DBMS enforce constraints you are (1) taking no advantage of database management (2) you are throwing out consistency and data integrity. Those who don't understand this should not use databases.
- 5/30/2017 3:39:21 PM
"Please stop insisting that Primary and Foreign keys are mandatory. They are good design habits but by no means mandatory."
I just took this to be a sloppy way of saying that defined constraints are not mandatory.
- 5/29/2017 5:55:20 PM
I dk what you mean by "direct".
A PK is a relation attribute that represents in the database an identifier of an object, a fact about which is represented in the database by a tuple that is displayed as a R-table row. Since objects are unique in the real world, a uniqueness constraint on the PK attribute ensures that its values are unique.
A FK is a relation attribute that represents in the database a relationship between objects of distinct types. Both PK and FK must be defined on the same domain i.e., they must represent the same object property (mean the same thing). Since the FK values must be consistent with the PK values, the two relations are subject to a referential constraint enforcing matching between the two sets of values.
I prefer to say that a PK represents identification and the FK a cross-reference.