I have recently started to work with RavenDB.
Here's a traditional example in relational db:
EmployeeType
ID:1 TYPE:DEV
ID:2 TYPE:QA
Employee
NAME:FRED TYPEID:1
NAME:JACK TYPEID:2
From what I understand of RavenDB the type would be included with the employee:
Employee
NAME:FRED TYPE:DEV
NAME:JACK TYPE:QA
Would there then be a need for the EmployeeType table?
If not, if you were to display a drop down list of employee type, would you just select distinct(Type) from Employee?
If you were to do the above, how would you add a new employee type, without entering a new employee (or editing an existing one)? Or would you just keep a list in code somewhere?
And lastly, if the text for an employee type were changed, it seems like you would then need to update all the employee records. What if there are 100,000 employee records?
I'm new to Raven (document databases), so any insight to help me better grasp the different paradigm would be appreciated.
Would there then be a need for the EmployeeType table?
There would be to fulfill requirements of the next question. Also, this type of reference data could just be stored in a single document, not a document collection. You may also maintain a hard-coded list, bypassing a database all together.
If not, if you were to display a drop down list of employee type,
would you just select distinct(Type) from Employee?
No. Select from an employee types document. Selecting distinct from an employees tables would tell you the types of employees on record, not the available employee types.
And lastly, if the text for an employee type were changed, it seems
like you would then need to update all the employee records. What if
there are 100,000 employee records?
You're facing what is effectively a trade-off between relational databases and document databases. You have a few options. You can reference employee types from employee documents by an ID which points to an employee type document collection. In this way, you can change the employee type name in one place. However, the trade-off is that RavenDB will need to include (join) that two documents to return an employee with a type. The alternative is to avoid an employee type ID and store the type directly in the employee document and when names need to be change you would run an update across all documents. Take a look here from the RavenDB docs.
Related
I'm somewhat new to VBA and Access, and yet I need to make an access database for work. I made the basic tables I need to track what we need, but I'm stuck trying to assign the supervisors to the employees. I have four tables, two of which are:
Employees, which includes basic information like their name and position
Supervisors, which includes their name (linked to the above "name" field), and date promoted
I want to be able to go back to the Employees table and add who is their supervisor in a lookup field, but when I make a lookup off of the "names" from the Supervisors table I only get a number. When I make a lookup off the "names" in the Employees table itself, it gives me everyone to choose from. I want to limit the choices in this field to only supervisors so that a) other users don't mess it up and b) it's easier to use.
If you give me code in VBA or C++, I can understand it to a beginner-to-intermediate level, and can make a macro button if needed. However, I'm thinking this is probably a problem of relationships or labels in my database. Please help if you can. Thank you!
If [Name] in Supervisors table actually stores a number then combobox RowSource needs to be a query that joins tables so can retrieve actual name.
Instead of a separate Supervisors table, have a yes/no field in Employees that flags record as "Supervisor" and restrict combobox list to those records.
Advise not to build lookups in table. http://access.mvps.org/Access/lookupfields.htm
Name is a reserved word and should not use reserved words as names.
I'm taking a DBMS course and I need to design and build my own DB. I have a database for a hospital where doctors,nurses,support staff etc are in a ISA relationship to an Employee entity with the rest of the data like the name, address , salary and the rest of the employee data.
Designing a form, I want to be able to add an employee with all of their data in one form.
Is there a way to do a "conditional table" of sorts where if i select "doctor" from a drop-down i get to add to the doctor table too, and same for the rest of the entities under the ISA relationship?
Thx!
As a general rule, when dealing with data, you do NOT flip or switch tables for a given form or relatonal database design.
So, for example. If I have a table of customers. Well, now if I want to mark some of the customers as plumbers, and others as doctors? I don't create two tables.
All I would do is add ONE column to that customers table and it would simply allow me to set the type of customer. The reason for this design is "many" but some significant reasons are:
For each new type of customer, you would not create a new table. Worse, all of the forms, the reports, the SQL, the code you write? Well, all of that code would have to be modified EACH time you create a new table. So, you SIMPLY cannot adopt a design in which the concept of changing a table is part of that process.
Forms are bound to ONE table. For related data, you in most cases will use a sub form.
So, think of even a accounting system. They can have huge numbers of customers, and as a result, you can "query" that table to give you all customers. Or you might ask how many accounting firms are in the customer list. Or make a report that summeries by customer type a "count" of each type of customer.
So, buidling forms, or reports? They cannot on the fly "change" the tables they are using.
So, in place of a tables called:
SalesJan
SalesFeb
SalesMar
etc.
Well, now you can't query sales from Jan to mar, because the data is in different tables.
So, what you do is have ONE table called "sales", and you add ONE column of the date. Now, at the start of each new month, you don't have to create a new table.
Now, of course in some cases it makes sense to create a separate table. For example, a table of customers, and a table of employees in a database is just fine. It makes sense in this case to use two tables, since the information about a customer and what they can do and the kind of information is VERY different then how you would deal with employees.
So, with above? Well, if I need to print mailing labels for all customers and all employees? That would require two different reports. And very likely the table structure for the two tables is different.
Bottom line:
If you working on design or form or report? And you needing to try and change the table that the form/report/code etc is going to operate on? This is a sign that your design approach has gone complete off the rails and is the wrong design.
So, in the case of doctors, nurses etc.? Well, they are all hospital staff, and MOST of the basic information about such employees will be common, much the same, and thus a SINGLE table of "employees" makes the most sense. You would only need a nice "employee type" combo box on that one form, and thus you can add/enter/edit/search any employee in that one table.
The fact that you "want to search" for a employee show that all these people "are" employees and thus belong in one table. And the basic information about all employees is going to be the same anyway. If you find you are attempting to create a new table but with near identical structures over and over, then just like a new table for each month sales, or a new table for each new kind of employee? Simply add the "one" column that allows you to make that distinguish, and not a whole new table.
Now one COULD even attempt to put patients in the same table, but then again, dealing with patents as opposed employees is a considerable different kind of "thing".
So employees are employees - even different kinds. (manager, cleaning staff etc.).
And patients are patients - even different kinds (long term care, emergency etc.).
I would like to store people's information in the database (table). Every person can have a different set of properties. I would like to store all these properties. But creating fixed number of columns does not make my application scalable.
So, another approach is to store these values inside key-value tables which leads to tables with a few columns but a huge number of rows.
So I am wondering if there is another way of storing these information which is also easy and fast to query.
What Database are you using.
One solution (if your DB supports) could be storing the person's information in an XML Format.
If you are stuck using SQL Server for this task, you can leverage its XML Support. Notably, you can use XPath.
Using XPath Queries in SQLXML 4.0
No matter how your data is organized conceptually, its the DBSM's job to make it fast, so usually, you shouldn't have to worry about whether your query is fast.
The first and most obvious, but also the least recommended way is using alter table which will allow you to modify the table later on.
The more recommended route is decomposing your table into many tables and relating them with primary keys.
So your person might have as a primary key social security, and attributes name, last name, street address, street name, postal code
Then you would decompose the table into (in pseudocode)
Table Person: social
Table Address: social, street_address, street_name, postal_code
Table Info: social, first_name, last_name
Then you can join them with
Select Person.social_security, first_name, last_name [...etc...] from Person, Address, Info where Person.social = Address.social and Person.social = Info.social
Then you can keep adding more tables as needed. There's no problem with having lots of rows in the other tables, and only a few in Person, and this is the recommended way because it lessens the number of empty spaces if a person doesn't have an address but does have a first name and last name, and for many other reasons.
So I am pretty new to SQL and databases in general(only designed a very simple one for a minimal site), and I'm trying to work out the best way to design some models for a heavily DB driven site. So take for example, a user uploaded gallery. I have a gallery table with sensible columns like date uploaded, name, etc., and galleries can belong to one category, of which there will not be that many (at most like 6). Should I have the category be a column of the gallery table? Or have a separate table for categories and have a many to one relationship between the category and gallery tables? I would like to do things in my views like sorting all galleries in a category by date uploaded, is there a performance/convenience difference between these? Having the category be a column of the Gallery table certainly seems easier to deal with than me, but I'm not sure what is the best practice. Thanks.
First of all, you need to understand the conceptual difference.
As a rule of thumb, you are safe to consider the following equivalence:
Table ~~~ Entity
Column ~~~ Attribute
So, when you need to add a new piece of data, in relation to an Entity (an existing Table), the question you can ask yourself is:
Is this piece of data an attribute of the entity?
If the answer is yes, then you need a new column.
For instance, say you have a table describing the Student entity:
Table Student:
[PK] Id
[FK] IdClass
Name
Surname
Say you want to also add the GPA of each student. This is obviously an attribute of the student, so you can add the GPA column in the Student table.
If however you wish to define the Department for each Student, you will see that the department is not an attribute of a Student. The Department is an entity, it exists and has its own attributes outside the scope of the student.
Therefore, the attribute of the student is the affiliation to a certain Department, but not the department itself.
So, you will create a new Department table, and use the Department.Id as a FK in the Students table.
I hope this helps. Cheers.
If you have a one to many relationship between categories and galleries, you want category to be a separate table.
When in doubt use a separate table.
It does not have such a big impact on speed and you will gain more control.
I'm looking at this company's database design, and would like to know the purpose of their design, ie store relationship in one table and the data in another, why do this?
They have this,
EMPLOYEE
Id (PK)
DepartmentId
EMPLOYEE_DATA
EmployeeId (PK)
First Name
Last Name
Position
etc...
Rather than this...
EMPLOYEE
Id (PK)
DepartmentId
First Name
Last Name
Position
etc...
...OR this...(employee can belong to many departments)
EMPLOYEE
Id (PK)
First Name
Last Name
etc...
EMPLOYEE_DEPARTMENT
Id
EmployeeId
DepartmentId
Position
That's a link table, or join table, or cross table.. lots of different names.
How would you assign an employee to two different departments with your design? You can't. You can only assign them to one.
With their design, they can assign the same ID to multiple departments by creating multiple records with the employee ID and different department ID's.
EDIT:
You need to be more specific about what you're asking. Your first question seemed to be asking what the purpose of mapping table was. Then you changed it, then you changed it again.. none of which makes much sense.
It seems now that you are asking what the better design is, which is a totally different question than what you originally asked. Please state specifically what question you want answered so we don't have to guess.
EDIT2:
Upon re-reading, if this is the actual design, then no.. It does not support multiple department id's. Such a design makes little sense, except for one situation. If the original design did not include a department, this would allow them to add a department ID without modifying the original EMPLOYEE_DATA table.
They may not have wanted to update legacy code to support the Employee id, so they added it this way.
Purpose of design is determined by business rules.
Business rules dictate entity (logical model perspective) / table (physical model perspective) design. No design is "bad" if it is built according to the requirements that were determined based on business rules. Those rules can however change over time -- foreseeing such changes and building to accommodate/future-proof the data model can really save time, effort and ultimately money.
The first and third example are the same -- the third example has an extraneous column (EMPLOYEE_DEPARTMENT.id). ORMs don't like composite keys, so a single column is used in place of.
The second example is fine if:
employees will never work for more than one department
there's no need for historical department tracking
Conclusion:
The first/third example is more realistic for the majority of real-world situations, and can be easily customized to provide more value without major impact (re-writing entire table structure). It uses what is most commonly referred to as a many-to-many relationship to allow many employees to relate to many departments.
If an employee can be in more than one department, then you would need a mapping table but I'd do it like the following:
EMPLOYEE
Id (PK)
First Name
Last Name
DEPARTMENT
Id (PK)
Name
EMPLOYEE_DEPARTMENT
EmployeeId_fk (PK)
DepartmentId_fk (PK)
Position
This would allow for multiple positions in multiple departments.
You would do this if an employee can be a member of multiple departments. With the latter table, each employee can only belong to one department.
The only remotely good reason for doing this is to implement an extension model where the master table identifying unique customers does not include all the data for customers that is not always necessary. Instead, you create one core table with the core employee data and and extension table with all the supplementary fields. I've seen people take this approach to avoid creating large tables with many columns that are rarely needed. However, in my experience it's typically premature optimization, and I wouldn't recommend it.
In contrast to many responses, the model included does not support multiple departments per employee - it is not a many to many mapping approach.