On Tue, 14 Jun 2016 16:27:29 +0000 "Drago, William @ CSG - NARDA-MITEQ" <william.dr...@l-3com.com> wrote:
> Once the part has been grouped into a set (Matched=1) it receives a > unique permanent serial number and the temporary serial number can be > reused, so (Model, TemporarySerialNumber) doesn't have to be unique > anymore. Information about what parts belong to what set is stored in > a different table. > > So is using a conditional constraint in this case okay, or is there a > better way? It's OK, Bill; it was OK before I posted. I'm only suggesting an alternative you might like better. You pasted your particulars into my generic description, and they fit perfectly. You have two sets: 1. Parts with a unique, permanent serial number. 2. Parts with a temporary, reusable serial number. You could remove the latter set to a new table, perhaps "UnmatchedParts", having the characteristics you want, namely a primary key or unique constraint on (Model, TemporarySerialNumber). Then you don't need the Matched bolean column in either table, solving your original problem (a conditional constraint). Then you have a view, create view vParts as select 1 as Matched, * from Parts UNION select 0, * from UnmatchedParts ; I think there's a natural tendency to put similar things in one table when they share common properties, sometimes by adding a discriminator column. I've seen lots of tables like that, and designed some myself upon a time. SQL encourages it, because that way you can write just one INSERT, etc., and just set the flag right. When you push hard on such a table, though, by trying to do things right, you wind up with little conundrums (conundra?) like the one you posted. They grow out of the fact that the things aren't the same. They're just a smidgen different, so they need to be tweaked just so, and before you know it you either have to lean on some oddball feature of the DBMS, or punt. If you separate them, the you might have more query text, but each one will be simpler and easier to understand. HTH. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users