The trouble with BCNF is that a requirement to be in BCNF may prevent complete representability of functional dependencies (ie it may not be possible for the key constraints in the DB to enforce all the simple functional dependencies in the data model); so I prefer to stick to EKNF (which is 3NF plus extra separation, but doesn't go quite as far as BCNF). Every schema which is in EKNF is also in BCNF unless there are multifunctional dependencies in the data model which would constrain BCNF to miss complete representability of simple functional dependencies (and a similar statement can be made about EKNF and 4NF), so the cases where EKNF has problems which BCNF doesn't are exactly the cases where BCNF has problems which EKNF doesn't - so there's always a trade-off on which set of problems you want to live with (coding round anomalies caused by multifunctional dependencies which could have been eliminated by BCNF [or in some cases, by 4NF] or coding to enforce simple functional dependencies which woul have been key constraints in EKNF; since EKNF generally delivers better performance that BCNF when they are actually different (because the joins use a smaller number of tables) and because I object to having to write code (as opposed to key constraints) to enforce simple functional dependencies more than I generally object having to code out multifunctional dependency related anomalies I usually reckon the trade-off is best resolved by going for EKNF.