On 13.09.2017 22:23, Michael Van Canneyt via Lazarus wrote:
create table customer (
C_ID INT Primary key,
C_FIRSTNAME VARCHAR(30),
C_LASTNAME VARCHAR(50)
);
CREATE table invoice (
I_ID INT PRIMARY KEY,
I_CUSTOMER_FK INT,
I_DATE DATE
);
ALTER TABLE INVOICE ADD CONSTRAINT R_INVOICE_CUSTOMER FOREIGN KEY
(I_CUSTOMER_FK) REFERENCES CUSTOMER(C_ID) ON CASCADE DELETE;
3 "rules" :
Prefix is always somehow related to table name. Usually 1 or 2 letters.
Occasionaly 3 (if you have close to 600 tables, 2 letters doesn't
always cut it)
Primary key is always Prefix_ID
Foreign key is always Prefix_FOREIGNTABLE_FK
The SQL you construct like this is always unambiguous, unless you use the
same table twice in a single SQL select there is never any need to prefix
the fields with the table name.
Interesting approach. I do the opposite: I always (really always, even
in simple statements) prefix the fields with the table name (and really
the full table name, not an abbreviation/alias) :) With it I get
unambiguity as well. And I really hate abbreviations since I fail to
remember them. :)
Everybody has their own taste - and it is good so. Otherwise we would
all want to marry the same woman :)
Ondrej
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
