Each reservation contains names of the guests & a company name.
Now, the guests may/may not belong in a company. (a booking may have a company as null)
Currently, I have:
Booking_table (booking_id, guest_id, company_id)
Guest_table (guest_id, guest_name)
Company_table (company_id, company_name)
Guest_booking_history (guest_id, booking_id)
Company_booking_history (company_id, booking_id)
Am I doing this right? Any suggestions in designing the database?
An alternative would be:
Booking_table (booking_id, guest_names, company_id)
Company_table (company_id, company_name)
It's mostly good, but I'd consider adding the company to the guest, and maybe remove the company from the booking table. Something like:
Booking_table (booking_id, guest_id)
Guest_table (guest_id, guest_name, company_id)
Other than that, I think your database is missing a lot of important data - dates, customer info, etc, but that's a whole other issue fully dependent on exactly what you want to achieve with the database and software.
Seems like it would be usefull to have the booking dates, and booking needs likely needs to be linked to a table of rooms.
It all depends on what data you want to keep and track ;)
Other then that, if this is homework mark it as that.
Related
There is a Book table that is always unique with title, edition, and author.
And I want all bookstores to add their books, but different bookstores can have the same book with different pricing. So I come up with this table design.
So when one bookstore tries to add a book and the book is already been added by another bookstore the current bookstore should have to just fill in the pricing detail, not including the book detail.
The problem with this is, what if the book detail already been added has some missing or incorrect info? in this case, the current bookstore can flag and moderators or admins can fix it.
Is there any better way to achieve this? I don't comfortable with this design logic at all.
Your design makes sense. You want to keep the "static" information in 1 table, and link "dynamic" information like you did.
Your other question is related to data integrity. You can put "not null" conditions on fields to ensure all fields are filed, but garbage entries are always possible. This is a universal problem.
Potential solutions to mitigate this:
any and all data that can be selected instead of typed in should be linked via another table. Ex:
BookGenre
bookgenreid PK
genre CHAR
Book
bookid PK
genre FK, BookGenre.bookgenreid
...
So you store all possible genres in a separate table, so your users cannot invent new genres or mistype values. Same for authors, countries, ... This makes it easier to build queries as well and avoid things like [ SciFi, Science Fiction, Sciance fiction, ... ]
not everyone should be able to enter new books in the system. Ex. when I worked at a wholesale distributor, only a select group employees could create new products in the database, and they had established a convention on how to do it. They worked closely with purchasing and receiving. You will need to dedicate "data administrators".
So try to control as much as you can in the database and - or the application. Avoid free text fields as much as possible, as users will always think of new ways to mess it up. Ex. at work currently we have a HUGE project to standardise addresses between unlinked systems. It is a enormous undertaking, which involves AI. All this only because no 2 persons enter addresses exactly the same.
I'm looking to create a database for tracking purposes. For the purposes of this question I have abstracted it a bit and transformed it into a Product Design tracking database.
I'm trying to make it as normalized and efficient as possible.
Essentially I want to be able to track Employees and what designs they've participated in.The queries I want to run aren't particularly complex. I want to be able to query how many employees participated in the design of a specific model, what models and products an employee has designed, how many employees designed a product, etc. The products would be redesigned every year or half year.
My concern is how I'm managing the many to many relationship between models and employees. In the example provided I have a Design table between the Model and Employee Table. This will essentially be a dump of all Employees designers, which both resolves the many to many relationship (which I understand to be a bit of a bad thing to have) and make query design relatively simple. I also assume I can index it by either Emp_ID or Model_ID to make it more efficient.
However I'm worried this table may get a bit unwieldy over time. In its current role I could make this database very inefficient and probably not notice any degradation in performance. However I'm hoping to make this relatively scale-able as I want to make this easy to admin (whether I admin it or someone else takes over) and I'm hoping to add features over time (a CRM-like functionality for example).
I was thinking I could create a table to for each employee and track design projects by having them in a separate empID_design table, but that also seemed very unwieldy. Essentially every other way I thought up on how to do this ended up with creating a large number of tables versus inserting a Row.
One other thing was I wanted to be able to track project managers. In the current form I thought tracking it in the Design table made sense. I don't think the Project Mgr would change mid-design but is there an elegant way to track it if they did?
Any help or advice you can provide is appreciated. I'm a bit rusty with Database Design and ERD Design, so if you notice something that doesn't make sense, its more likely a mistake I made as opposed a fancy nuanced design I thought up.
To give a basic idea of what each table could be representing:
Company: Black and Decker
Product: Rotary Tool
Model: D-5230
Designed by: George Santos, Kevin Smith, John Rodes
Project Manager: Kevin Smith
Thank you in advance!
ERD Diagram: http://i.stack.imgur.com/flo4l.png
It sounds to me like the intersection table between model and employee ought to be a role table, in which each row has:
An employee ID
A model ID
A role ID: designer, project manager, lead designer, etc
In that way an employee could even have multiple roles on a project.
So I'm fiddling with how you could design the basic db schema for a webshop. Sure, there's a lot of missing details here and there, but I just want to get the most basic stuff right.
Some basic requirements for the shop, which I'm trying to make a schema of:
The shop has an inventory of products. Each product has a price, but this price should vary depending on sales. Customers can make orders for multiple products at a time, and should be able to see their order history. When the order has been completed, there should be a track and trace number.
So, the following image is what I've come up with so far. I'm sure something is missing, I'm just not really sure what, also how to model the dynamic price aspect.
I think this is the according to your question give a flow of it how to create a schema and Additional that Link here please visit once you will find some amazing part.
A common way to handle variable price would be to introduce a rebate schema. This can be implemented as association class between Product and Sale by adding some rebate to amountSold. Of course there are many different ways, but this is one at hand.
I'm missing a relation between Order and Customer.
Not sure what you intend with the Inventory aggregating ProductList. To me a Inventory lists Product. There might be the need to a store location and a PurchasePipe
I just joined this site and this is my first question , I hope my question it's according to the StackOverflow question policy.
I'm designing a DB for Phone book which has the following abilities
Contact have 2 types (Company or Person)->ContactType
And I want each contact to have as many Emails, Phones Numbers, and Addresses as it wants.
And I want to specify which Person works in which Company , so I can show not only a Company Contact detail but also list of its employees and their jobs in that Company and their Contacts (CoEmpJob table)
I have designed a db diagram which is shown in the link below, is it well structured or can I achieve what I want in some better way?
Thanks in advance.
My Phone Book Design
As the design stands, you're missing a few things, such as a Companies table and a ContactTypes table. There seems to be no foreign key in the CoEmpJob table linking to the Contacts table.
In the Phones table, I personally wouldn't use a prefix field (unless you wish to display contacts by phone prefix), in which case every phone number is guaranteed to be unique, in which case the PhoneNum field becomes the primary key and the PhoneID field is unnecessary - but you might have the case in which husband and wife are in the same database; whilst they almost certainly have different mobile numbers, they almost certainly share the same home phone number! In this case, your design is correct.
I don't know how many people have more than one address (I would think very few, if at all) which means that the fields of the Address table could be moved into the Contacts table.
(Added)
As regards the companies, if you want to specify which Person works in which Company, then you will need a companies table (missing) and a join table (CoEmpJob). In the real world, this design would also require more tables - a join table can show which contacts are connected to which companies and what their current jobs are, but people change jobs (and companies) and so such a design would not store any history. Also, it is customary to link people (employees) to a department - and it is possible that one person can be connected to more than one department at a time, meaning that you will need another join table. This can get very complicated - it depends on what you want.
Your comment suggests that you want to store company data in the contacts table - this is a very bad idea; they should be kept separate.
My spider sense is tingling, but I've been thinking about it for 2 hours now and I'd like some more feedback from the hivemind.
I'm creating an application for a school. Its supposed to handle students, teachers, courses, honor roles, grades - the works.
I was wondering how to handle the change of years after each year.
Students move up a grade (or don't).
Teachers are assigned to different grades as their homeroom teacher.
Grades are saved for the year.
There's also the matter of auditing. I need to have an easy way to pull up records from last year or the year before. See what teacher gave which course at what grade at what year.
The problem I'm having is how to handle this.
My thought was to create a new clean database for each year as they come along. So at the end of this year, I'd go to the school and create a new database for them named FooSchool2012 and programatically let the end users change the database they want to use via a connection string.
Since I'm using an ORM it's only a matter of changing the connection string as the databases are the same.
But this reeks of bad design and crappy engineering to me.
Usually my gut is right, so hopefully you guys can let me know of some alternatives on how to handle this.
No, I would not create a new table or database for each year. It breaks first normal form. Every table will be a duplicate except for the name. It's a poor design. And a maintenance headache. Who's going to create the new database, load the schema, and then change all the URLs? If you change the schema after a few years, will you have to change all the back editions as well so people can query the historical data?
Nope, not a good design at all.
It's common to move historical information out into reporting/data warehousing databases. But the scheme you're suggesting is reminiscent of old, mainframe, VSAM flat file methodologies. I'd use relational databases the way they were intended to be used.
I'm sure your solution could be made workable, but it does seem a little needlessly complicated. Couldn't you accomplish the same thing in a single database by referencing the school year? You may want to think about which entities make sense to have "effective dates" (i.e., a start and an end time). The 3rd grade teacher may change mid year, for example, but you could handle that with effective dates.
My thought was to create a new clean
database for each year
If you thought about this for two hours, and your best idea was to create a new database for each year, you're the wrong person to design this database.
That's an observation, not a criticism. You just need to learn a lot more of the fundamentals before you tackle a project like this one. You'll just get frustrated, and the school will suffer.
You need to spend A LOT of time on your database design. Think about maintenance in the long run, it needs to be as easy as possible. The best way is to create a relational database, research bridge,validation, and base tables. To answer your question, I would not do a table for every year. The best way is having the student grade data mapped to a specific unique id representing that student's specific course ID.
I would think about creating a table for each of the nouns:
instructor - PK instructorID,instructorName..
(any other 1:1 instructor information)
Student - PK studentID,StudentName..
(any other 1:1 student information)
Course - PK CourseID, CourseName, CourseDescription..
(any other 1:1 course information)
•Teachers are assigned to different grades as their homeroom teacher.
on the 1:1 instructor table you could have a column called HomeroomGrade and then you
update that column with the current grade. If you wanted to keep a history of the grade
you could have the instructor table be a composite key with another column incrementing up
for the current record.
•Students move up a grade (or don't).
You will need another table showing the relationship of students to a unique courses
grades for that year, but first you need to map the instructor to that specific course.
PK InstructorToCourseID
InstructorID - FK
CourseID - FK
Year - FK
then yet another table mapping the unique course to that student with the grade..
PK InstructorToCourseID FK from previous table
PK StudentID - FK from student information table
Grade
Sorry if im general and vague, but this should give you some ideas on the relationships that can be created.