relational-database

Recently I've been working a little with MongoDB and I have to say I really like it. However it is a completely different type of database then I am used. I've noticed that it is most definitely better for certain types of data, however for heavily normalized databases it might not be the best choice. It appears to me however that it can completely take the place of just about any relational database you may have and in most cases perform better, which is mind boggling. This leads me to ask a few questions: Are document-oriented databases being developed to be the next generation of databases

I am trying to show the following in the ER diagram: There are instructors and courses, a course is taught by only one instructor whereas an instructor can give many courses. My question is, is there any difference between two diagrams, in other words, does it matter which line we turn into an arrow, or what only matters is only the direction of the arrow? Also, if we think about the mapping cardinalities; is it 1 to many or many to 1? If we think in terms of courses, then it is many to one but if we think in terms of instructors, then it is one to many. How do we decide this? Thank you. In ER

After reading a shocking article written by Bret Taylor (co-creator of FriendFeed; current CTO of Facebook), How FriendFeed uses MySQL to store schema-less data , I began to wonder if there are best practices for using a RDBMS such as Oracle, MySQL, or PostgreSQL for storing and querying schemaless data? Few people like to admit they're using a relational database when NoSQL is the new hotness, which makes it difficult to find good articles on the topic. How do I implement a schemaless (or "document-oriented") database as a layer on top of a relational database? thats the classic article in

I have 3 types of users: Admins Suppliers Employees Each user type will have different user interface and access different types of data. Their only similarity is they are using one web application but they access totally different things. Is it better to put them all in one user table like tbl_users or is it better to create tbl_admins, tbl_suppliers, tbl_employees? What you need to consider when designing tables is not necessarily what they'll have access to and how that is similar/dissimilar, but rather how the user levels themselves are similar/dissimilar. For example, if the user types

Can someone please explain the difference between 3NF and BCNF to me? It would be great if you could also provide some examples. Thanks. Mosty Mostacho The difference between 3NF and BCNF is subtle. 3NF Definition A relation is in 3NF if it is in 2NF and no non-prime attribute transitively depends on the primary key. In other words, a relation R is in 3NF if for each functional dependency X ⟶ A in R, at least one of the following conditions are met: X is a key or superkey in R A is a prime attribute in R Example Given the following relation: EMP_DEPT(firstName, employeeNumber, dateOfBirth,

I have 2 tables as you will see in my posgresql code below. The first table students has 2 columns, one for student_name and the other student_id which is the primary key. In my second table called tests, this has 4 columns, one for subject_id, one for the subject_name, then one for a student with the higest score in a subject which is highestStudent_id. am trying to make highestStudent_id refer to student_id in my students table. This is the code i have below , am not sure if the syntax is correct: CREATE TABLE students ( student_id SERIAL PRIMARY KEY, player_name TEXT); CREATE TABLE tests (

I've been trying to model product variants and thought that I might need to use EAV. I might have been able to do it without EAV, but I'm concerned that I might have missed something. Here's my design: Here's what I am trying to represent: A product can have 0 or more product variants (e.g. a t-shirt product may have size and color variants). A product variant can have 1 or more product variant options (e.g. the size variant can be small, medium, large). An SKU is comprised of 1 or more product variant options (the product_variant_option_combination table would contain all the possible

In developing a shopping cart application I've found that I needed to save settings and configurations based on the administrator's preferences and requirements. This information can be anything from company information, Shipping account IDs, PayPal API keys, notification preferences, etc. It seems highly inappropriate to create a table to store a single row in a relational database system. What is the appropriate way to store this information? Note: my DBMS is SQL Server 2008 and programming layer is implemented with ASP.NET (in C#). I have done this two ways in the past - a single row table