15,230 reputation
83768
bio website
location
age
visits member for 2 years, 5 months
seen 1 hour ago

I seek not to know all the answers, but to understand the questions.

- Kwai Chang Caine


Jan
12
comment What are the differences between server-side and client-side programming?
@Deduplicator You're right. Validation must be done in the server. A redundant validation in the client could be used to avoid server calls when speed is very critical. I'll edit the answer.
Jan
10
comment Users in SQL databases
When you say "Simple implementations almost invariably to protect security and privacy", do you mean "Simple implementations almost invariably *fail* to protect security and privacy" ? Verb is missing.
Jan
8
awarded  Nice Answer
Jan
7
revised Storing menu items with user permissions
some grammar and style corrections plus an adendum explaining set theory
Jan
5
comment Is it good design to put abstract methods in an abstract class even though the methods are already defined in its interface?
+1 That allows for the template method pattern. en.wikipedia.org/wiki/Template_method_pattern
Jan
4
comment Effect of denormalizing
I suggest you edit your question replacing it with @MichaelT sugestion in Meta (copy & paste will do), but indicating in the diagram the PK of the tables (mainly UserAccount). Please note that a table with no PK is a non-conformity regarding relational database principles.
Jan
4
comment Effect of denormalizing
If UserID could have been he PK of UserAccount, then the relationship between entities User and Account is 1:1, not 1:m. And that's the reason you say "Uniqueness constraint to ensure that a userId appears no more than once" and not "Uniqueness constraint to ensure that the combination of a userId and an accountID appears no more than once". The question needs to be a lot more clear than it is right now because leaves to many asumtions to the reader.
Jan
4
comment Effect of denormalizing
I think is was clear the existence of the table UserAccount was not a design decision but an answer to a prohibition to add a FK no table User.
Jan
4
comment Effect of denormalizing
@RibaldEddie is right, UserID+AccointID should be the PK of UserAccount and not just a mere unique constraint. Most RDBMS would only allow a FK to a PK, not any unique index.
Jan
4
comment Effect of denormalizing
@ChrisW Reading your prior-to-last comment I guess I didn't understand the question. Question states "These tables have a userId column" That's why I thought relatioship was with User and not both User and Account and that the whole AccountID-denormalization thing arose from the fact that you weren't allowed to modify the User table. Take from my answer whatever could be useful to you, if any, given I didn´t understand the question but I suggest you improve the question and make some things more evident so you can get better answers. For example mgw854 also misunderstood the answer.
Jan
4
comment Effect of denormalizing
@ChrisW Having a UserId and a AccountID columns in sales violates 2NF/3NF. Violating 2NF/3NF means you could have update anomalies, meaning you will need to update Sales if a user need to be moved to a different account. The dependence Sales and Account is transitive.
Jan
4
comment Effect of denormalizing
@ChrisW I gave you an example of an hypothetical situation in which it's necessary to move an user to a different account becasue they want to delete an account, or becasue they added an user to the wrong account by error. That's the type of things that never happen until they happen. Another example is deleting an user. Also I made a mistake, thought the reason for wanting to denormalize was UserID but it's AccountID, I corrected that in the answer, you can see the edit if you see the edit history. To continue...
Jan
3
revised Effect of denormalizing
added 13 characters in body
Jan
3
revised Effect of denormalizing
added 17 characters in body
Jan
3
revised Effect of denormalizing
added 96 characters in body
Jan
3
revised Effect of denormalizing
added 96 characters in body
Jan
3
revised Effect of denormalizing
added 234 characters in body
Jan
3
comment Effect of denormalizing
@ChrisW I edited the answer to reflect both that the relationship is 1:m and not 1:1 as I thought, but not m:m as an UserAccount table would seem to indicate and why the views saves you from having to write the join yourself in every query.
Jan
3
revised Effect of denormalizing
added 234 characters in body
Jan
3
answered Effect of denormalizing