enter image description here
enter image description here
Hello, I am doing a homework, the tables I added are obliged to add. It will be like a company website. But since we just started to learn SQL server management studio I don't know how to connect/associate things. For exp. which table needs to have it's own id or which id needs to be connected with. Even a little help is okey, I am so lost.
Even though this question is very vague and need a lot of research to understand the whole concepts. I can suggest the following topics to understand database structure
Primary Key and Foreign Key
Relations in Database
Normalization
To understand these things you must have clear understanding of Database entities and structures. Tables,Columns,Entries
Should I build the relationships with the database schema or deal with them programmatically?
For Example When I build the database in MSSQL I can to not build the relationships and deal with the relationships programmatically like checking if a key is exist as a primary key in another table and determine upon that to insert the new row to the table or not.
could anyone advise me if it is a good practice or not.
DO make relationships between tables explicit by declaring foreign key constraints.
I do not see any good reason for not doing this. Why are foreign key constraints a good idea?
Foreign key constraints are a simple way to help safeguard data integrity/consistency.
Constraints (not just foreign key ones) can also be seen as a form of "living documentation" (making things explicit and therefore discoverable, without having to guess).
You might still want to validate inserts in code; in that case you can look at foreign key constraints as a "safety net", in case your code fails.
(Regarding the second bullet point above: I have to work with one legacy database which is lacking some foreign key constraints that should by all means have been declared. This means that every time I have to make a change to it, I might inadvertently break an application that makes certain assumptions about the schema that aren't obvious by looking at the schema. Working with this database is very painful and error-prone. If I could change one thing about this database, it would be to add all missing constraints.)
it depends upon your need.
If you are designing OLTP applciation then builing relationship is good but if you designing datawarehouse DWH or datamart then it is advisable not to establish relationship in schema and handle it in code.
Recently I've asked a question about the best way to go to design a DB schema to support multiple types of users and interactions between them, one of the answers suggested that I use one table for each user type and Distributed Keys.
The thing is the only databases I actively work with are MySQL and SQLite and I've always done this kinda of work of maintaining the integrity of the DB on the programming side and never directly in the database, can someone point me to a detailed yet easy to understand guide on foreign keys, references and related subjects?
Thanks in advance!
EDIT: I'm interested specifically in MySQL usage examples and documentation, I've already searched in the MySQL manual but nothing useful comes up.
This isn't MySQL-specific, but there is some good stuff in here
http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/
I don't agree with him about the use of natural keys versus surrogate keys. I have found surrogate keys in general work better for primary keys, but if you have a natural key you should put a unique index on it to prevent duplication of data. Pay particular attention to the sections on:
- Not using SQL facilities to protect data integrity
- Trying to code generic T-SQL objects
- One table to hold all domain values
Another good starting place is:
http://www.deeptraining.com/litwin/dbdesign/FundamentalsOfRelationalDatabaseDesign.aspx [dead link Feb 17, 2015]
Try these:
http://en.wikipedia.org/wiki/Relational_database (has links to articles on Constraints, Foreign keys, Stored procedures, Indices, etc.)
http://en.wikipedia.org/wiki/Database
Try this one: Relational Database Design Basics or the Wiki. Give this a read too.
Specifically related to MySQL:
Referential Integrity in MySQL
Foreign Keys and Referential Integrity
Also this stackoverflow question: MYSQL and RDBMS
If you like to read books, try Beginning Database Design: From Novice to Professional by Clare Churcher. You can take a look it at google books.
Hugh Darwen has made his course on Relational Algebra/Database Technology publicly and freely available. Search for "An Introduction to Relational Database Theory" on http://www.thethirdmanifesto.com
It's introductory, so nothing "advanced", but at least you won't be told anything that is an outright violation of the theory.
I know, I quite dislike the catch-all survey type questions, but I couldn't think of a better way to find out what I think I need to know. I'm very green in the world of database development, having only worked on a small number of projects that merely interacted with the database rather than having to actually create a new one from scratch. However, things change and now I am faced with creating my own database.
So far, I have created the tables I need and added the columns that I think I need, including any link tables for many-many relationships and columns for one-to-many relationships. I have some specific questions on this, but I felt that rather than get just these answered, it would make more sense to ask about things I may not even know, which I should address now rather than 6 months from now when we have a populated database and client tools using it.
First the questions on my database which have led me to realise I don't know enough:
How do I ensure my many-to-many link tables and my one-to-many columns are up-to-date when changes are made to the referenced tables? What problems may I encounter?
I am using nvarchar(n) and nvarchar(MAX) for various text fields. Should I use varchar equivalents instead (I had read there may be performance risks in using nvarchar)? Are there any other gotchas regarding the selection of datatypes besides being wary of using fixed length char arrays to hold variable length information? Any rules on how to select the appropriate datatype?
I use int for the ID column of each table, which is my primary key in all but the link tables (where I have two primary keys, the IDs of the referenced table rows). This ID is set as the identity. Are there pitfalls to this approach?
I have created metadata tables for things like unit types and statuses, but I don't know if this was the correct thing to do or not. Should you create new tables for things like enumerated lists or is there a better way?
I understand that databases are complex and the subject of many many worthy tomes, but I suspect many of you have some tips and tricks to augment such reading material (though tips for essential reading would also be welcome).
Community wiki'd due to the rather subjective nature of these kinds of posts. Apologies if this is a duplicate, I've conducted a number of searches for something like this but couldn't find any, though this one is certainly related. Thanks.
Update
I just found this question, which is very similar in a roundabout way.
Not normalising
Not using normalisation
Trying to implement a denormalised schema from the start
Seriously:
Foreign keys will disallow deletes or updates from the parent tables. Or they can be cascaded.
Small as possible: 2 recent SO questions datatypes and (n)varchar
May not be portable and your "natural key" (say "product name") still needs a unique constraint. Otherwise no, but remember that an IDENTITY column is a "surrogate key"
Edit: Say you expect to store fruit with columns FruitID and FruitName. You have no way to restrict to one occurence of "Apple" or "Orange" because although this is your "natural key", you are using a surrogate key (FruitID). So, to maintain integrity, you need a unique constraint on FruitName
Not sure or your meaning, sorry. Edit: Don't do it. Ye olde "One true lookup table" idea.
I'll reply to your subjective query with some vague generalities. :)
The most common pitfall of designing a database is the same pitfall of any programming solution, not fully understanding the problem being solved. In the case of a database, it is understanding the nature of the data. How big it is, how it comes and goes, what business rules must it adhere to.
Here are some questions to ponder.
What is updated the most frequently? Is keeping that table write-locked going to lock up queries? Will it become a hot spot? Even a seemingly well normalized schema can be a poor performer if you don't understand your read versus write ratios.
What are your external interface needs? I've been on projects where the dotted line to "that other system" nearly scuttled the whole project because implementing it was delayed until everything else was in place, that is to say, everything else was inflexible.
Any other unspoken requirements? My favorite is date sensitivity. All the data is there, your reports are beautiful, the boss looks them over and asks, when did that datum change? Who did it and when? Is the database supposed to track itself and its users, or just the data? Will your front end do it for you?
Just some things to think about.
It does sounds like you've got a good grasp on what you're meant to be doing, and indeed there isn't "one true path" to doing databases.
Have you set up cascades for your hierarchical objects (i.e., a single delete at the 'head' of your object in the database will delete all entries in tables relating to that entry)?
Your link tables and 1:n columns should be foreign keys, so there isn't much to worry about if the data changes. By "two primary keys" here, did you mean indexes?
As for metadata tables, I've done them in the past, and I've not done them. A single char status with SQL comment can suffice for a limited set of statuses, but beyond a certain amount, or where you can think of adding more in the future, you might want to have a reference to another table of metadata, or maybe a char(8ish). E.g., I've seen user tables have "NORMAL", "ADMIN", "SUPER", "GUEST", etc for user type, which could have been 1,2,3,4,5 fkeys to a "UserType" table, but with such a restricted enumeration does it matter? Other people have a table of permissions (booleans of what a user can do) instead - many ways to skin a cat.
You might find some usable stuff in these slides:
[http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back][1]
I also am a beginner to database design, but I found this online tutorial very, very helpful:
Database design with UML and SQL, 3rd edition
The author explains all the fundamental design aspects of database, and in a very clear manner. Before I found this online guide I did a lot of wikipedia reading about normalization. While that helped, this author explains the exact same stuff (through 3rd normal form, at least) but in a much, much easier to read way. It pretty much addresses all your questions as well.
I'd suggest a good book. The best IMO is this:
http://www.amazon.com/Server-2005-Database-Design-Optimization/dp/1590595297/ref=ntt_at_ep_dpt_1
In addition to not normalizing, a common problem I see is overindexing, done before there are performance measurements that take into account your in-production mix of reads vs. writes.
It's really, really easy to add an index to speed up a query, and harder to figure out which one to remove when you have several that are getting updated during an INSERT or UPDATE.
The middle ground is to go after obvious secondary indexes (e.g., for common, frequent lookups by name on large tables), deferring other candidate indexes until you have reasonable performance tests in place.
Among other things, not using primary keys, not thinking ahead about whether you'll be using indexed views (and designing tables accordingly; I once had to drop and recreate a large table at my site to change its ANSI_NULL attribute to ON so that I could then use it with an indexed view), using indices.
I've recently been reading Louis Davidson's book on Sql Server Database Design and found it quite informative. I've picked up on alot of concepts that I didn't previously know alot (or anything) about. Primarily - I picked up on a way to set up database relationships that I hand't tried before.
Basically you use a surrogate key as the tables PK (an auto incremented id field) and then set up one or more Alternate Keys consisting of one or more Unique keys. Theese alternate kays would then be the values used for relationships (or the PK, if that makes more sense for the given relationship).
I remodelled an old database that was suffering from some data inconsitencies due to poor design to implement this, to me, new way of thinking.
On a database level it works great. Tha relationships function the way they're supposed to and the constraints are enforced in a consistent, reliable manner.
HOWEVER
I cannot get it to work properly in either the Entity Framework or in Linq to Sql classes. I read that in V1 of EF, it just flat out won't support this kind of relationship - so I moved to Linq to Sql to see if things would work out better. They seemingly did, as I got all the relationships automatically mapped out when I imported the classes from my database. The problem is that I can't save data to the database because of InvalidCastOperation exceptions as soon as I try to save data.
So I have a couple of questions:
Is this a limitation in Linq To Sql?
If so, is there a way to work around
it? Preferebly without implementing
sprocs for save, update and delete -
type safety is something I would
like to keep.
Is this way of designing database
relationships "correct" and/or a
good practice?
I hope someone can shed some light on this, as I'm getting quite frustrated about it. I can't really find any good material on the subject online - so hopefully someone here has an answer or can point me in the right direction.
Thanks alot!
EDIT - Solution.
What I ended up doing was this - I went back to using the Entity Framework in conjunction with a redesign of the database schema. I remodeled the relationships to rely on primary keys rather than alternate keys, in most cases. Where that was not an option - I made some modifications to the EF layout. I implemented the relationship that relied on the AK's - at which time EF complains. To get around that I had to delete the foreign key property on the many side of the relationship at which point EF accepts the relationship.
1) Yes.
2) If you can mark your alternate key as primary in the L2S model and unmark the real PK as PK then it will work.
3) From the db perspective there's nothing wrong, but as you have noticed it is not supported by L2S or EF. Personally I prefer to always have FKs pointing to the PK and only use AKs for lookups.