M
marian.edu
Guest
Thomas, my point is that a feature should not facilitate bad design, sometime this relative uniques is by design but most of the time it really isn't and either way it most of the time confuses developers not familiar with the initial thoughts of the designer like we had here... in fact most of us discovered that with surprise much the same way Joey did. Besides, this is 'documented' only in the knowledge base, there is nothing in data dictionary help that mention it nor that the tool gives any warning when non mandatory fields are used when creating a unique index. Back to your classic use case, the order indeed predates the invoice that's why, the worst case, the order number should be in the invoice table and not the other way around although most of the time it's quite valid to have multiple invoices for the same order (hence the many-many table). Anyway, peoples seem to see that as a feature so I'm not going to call it a bug, maybe I'm just not seeing the proper use case... much like the right to bear arms I guess, some of us just don't get it 
Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212
Continue reading...
Marian Edu Acorn IT www.acorn-it.com www.akera.io +40 740 036 212Continue reading...