Reputation
8,010
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
1 13 27
Newest
 Good Answer
Impact
~234k people reached

Nov
30
answered Database design for threading messages
Nov
14
comment Does my ERD account for my business logic
@Ciwan - I'm not sure you understood my point about resolving your m:n relationship into a full-blown intersection table. Please see my updated answer with an Entity Relationship Diagram for what I'm suggesting.
Nov
14
revised Does my ERD account for my business logic
Added ERD to clarify the advice.
Nov
12
comment Does my ERD account for my business logic
@Ciwan - A separate table for CC, BCC and TO would probably be a bad idea. Instead you should have a RECIPIENT table with a foreign key to CUSTOMER a foreign key to EMAIL and a TYPE column with values of {"TO", "CC", "BCC"} (or codes of your choice). The primary key of the RECIPIENT table would be all three of these columns. Using one table makes it much easier, for example, to find all of the emails sent to one customer, since you only have to read one table, not three.
Nov
8
comment Does my ERD account for my business logic
@Ciwan - Different template: how do you know what template is used by an email? There is no template table for the email to point to. How do you know what information is in the email template? (i.e. what data-driven fields?) Where is the list of available fields? Where is the mapping of fields to templates? Re: point C. storing multiple delimited strings in a big string field probably does not conform to the rules of normalization and is probably a bad practice, except in certain specific circumstances (which are documented well on this site and are beyond the scope of a comment).
Nov
6
answered Does my ERD account for my business logic
Nov
4
comment Relation that combines entries with their subsequent entries, in order of date
@Imray - I'd suggest googling around for "correlated subquery relational algebra" - Someone's probably figured it out.
Nov
4
answered Relation that combines entries with their subsequent entries, in order of date
Oct
29
comment SQL Server: Database integration and synchronization
@ced - I'm suggesting you do away with database B and just keep one database (A - your data warehouse).
Oct
28
comment SQL Server: Database integration and synchronization
My suggestion is that you create views in the main database instead of using tables in multiple databases. This would allow many users to have distinct subsets of your master data without having two data sources to get out of sync.
Oct
26
answered SQL Server: Database integration and synchronization
Oct
25
comment Are 2+ Foreign Keys a Bad Idea in any Association / Junction table?
@zdxai - You're welcome. We're all here to learn and help each other. If you're not comfortable yet with how to use the site and what the expectations are, I suggest you check out the FAQs, they're short and helpful.
Oct
25
comment Are 2+ Foreign Keys a Bad Idea in any Association / Junction table?
@zdxai - There is no data structure that can prevent a user saying a Prius is a Pickup Truck, but 3NF can prevent your database from the likelihood of these kinds of errors by limiting the number of times anyone says what type of vehicle a Prius is to just one record. If you had to do it on every Car record, then the likelihood of some records being right and some being wrong would be much higher. Consistency minimizes data entry, which also minimizes the chance of bad user input. Re: duplicate model names: yes a PK has to be unique, by definition.
Oct
25
comment Are 2+ Foreign Keys a Bad Idea in any Association / Junction table?
@zdxai - As long as your tables have a PK, it won't matter for the exercise whether the PKs are natural or surrogate (i.e. a string or a sequential number). You can make the names the PKs of their respective tables if you like, or you can make the keys integers to avoid the issue that David Cummins pointed out in his original answer.
Oct
25
comment Are 2+ Foreign Keys a Bad Idea in any Association / Junction table?
@zdxai - Draw your tables defined the way I suggested, and show me a sample population where you can have one example of a Prius being a Toyota and another example of a Prius being a Chrysler. Normal Forms can't stop your database from being populated with data that is wrong, but it can stop your database from being populated with data that is inconsistent. If you don't see the benefit of the normal forms then you haven't studied them hard enough. They are the #1 best practice in database design.
Oct
25
answered Are 2+ Foreign Keys a Bad Idea in any Association / Junction table?
Oct
21
comment Advantages of middle tables in one-to-many relationships
@SephVelut - Avoiding nulls is only important if you have a performance or space problem and your foreign key is populated only a small fraction of the time. A lot of people like to avoid sparse table, but extending that notion to an optional column is overkill.
Oct
20
answered Advantages of middle tables in one-to-many relationships
Oct
19
answered Good idea to include summary of frequently accessed data from another foreign-keyed table?
Oct
18
answered Database for a startup