Re^8: Avoiding SQL double jeopardy

Yes, teacher ID could be used as the session (pair) ID.

Available topics are expected to be quite dynamic. Someone could change the topic they offer each week, or stick to the same topic for long periods of time, or have several topics on offer at the same time.

Person / Employee is not an interesting distinction. This system is unrelated to any "business" database. In fact it's quite likely that visitors will take part in sessions.

Email addresses are stored in the People database as an ID, but can be changed. The autoincremented internal ID is the "authoritative" identifier in the system.

Perl is the programming world's equivalent of English

Comment on Re^8: Avoiding SQL double jeopardy

Replies are listed 'Best First'.
Re^9: Avoiding SQL double jeopardy by Pope-O-Matik (Pilgrim) on Jun 29, 2015 at 21:01 UTC
Someone could change the topic they offer each week If the same topic comes up twice, would it have the same spelling and case? it's quite likely that visitors will take part in sessions That answers that right there. :) Email addresses are stored in the People database as an ID, but can be changed. The auto incremented internal ID is the "authoritative" identifier in the system. One reason to sue an email address or the like is so the FKs make sense. No reason to hide information behind a number. As people may have the same name, ids are usually used, but a company email address or the like can help it be more meaningful. Regardless, i posted some tables and a view below that might help. If you like the approach but want a small change or two, please just say so!	[reply]

Replies are listed 'Best First'.

Re^9: Avoiding SQL double jeopardy
by Pope-O-Matik (Pilgrim) on Jun 29, 2015 at 21:01 UTC

Someone could change the topic they offer each week

If the same topic comes up twice, would it have the same spelling and case?

it's quite likely that visitors will take part in sessions

That answers that right there. :)

Email addresses are stored in the People database as an ID, but can be changed. The auto incremented internal ID is the "authoritative" identifier in the system.

One reason to sue an email address or the like is so the FKs make sense. No reason to hide information behind a number. As people may have the same name, ids are usually used, but a company email address or the like can help it be more meaningful.

Regardless, i posted some tables and a view below that might help. If you like the approach but want a small change or two, please just say so!

[reply]