Phil Leigh;303730 Wrote: > Hmmm m:m+RI... does not compute, Captain! > > Surely those m:m's have got to go (I know that means redesigning the > tables/indexes/keys but even so...) > > Also - as I'm sure you know - RI only makes sense for 3rd+ normal form. > > > Anyway, I'm sure you know exactly what you are doing! > > RI is really there (at least in this application) to cascade the > deletes...but on a clear/re-scan you are in a database truncate > situation... > RI won't help you there. Also (unless I'm missing something) RI is used > to enforce parent-child (1:m) integrity for inserts...I'm thinking > manual data entry here). In a "batch" situation, you can force all the > parents in first (sorry - starting to ramble now - it's been a long day > at the office)
Exactly! The m:m's plus the RI is not at all sensible. However, as I said, without access to the code, I'm in a position of trying to make the DB fit the code (tail wagging the dog?). The use of RI is ridiculous here because, as you said earlier, the only time the DB is written to is when scanning or compiling a playlist. Any checks on parentage would be done naturally in the code there. In fact, now I've removed it, it doesn't seem to have affected functionality at all (no surprise there). I've been ranting on about the feeling I've had about the database for some time now and it's nice to have some confirmation that this is an avenue worth pursuing. It would be much more worthwhile if the code could be changed to fit a more sensible design, though. -- larrettp ------------------------------------------------------------------------ larrettp's Profile: http://forums.slimdevices.com/member.php?userid=10191 View this thread: http://forums.slimdevices.com/showthread.php?t=45261 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
