Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want to make website for a school and because of that I need a suggestion. I'm trying to make a schedule table for each teacher would it be good to set them in one table or in different tables for each teacher(Note: Teachers can change the schedule from the site.)? The schedule table looks like this but in order to include the schedule of all teachers I wanted to add the ID column too.
And the second question about chatting. In order to add the chatting function to my site, I've opened a new table with name Chats. So the question is would it be good to open different tables for the chats or it would be good if I modify the Chats table each time new chatting called?
As a rule of thumb, if you have the same type of data, it should almost always(*) be stored in the same table.
So to answer your question more directly: you want to put all teacher's schedules in a single table. And then have a column in that table that identifies each row as being part of a specific teacher's schedule.
Again, the answer applies to the second question. All chats should go into a single Chats table. You would use a column to identify a chat (message) as being part of a conversation, as well as the participants.
(*) To further expand on the almost always above. The reason I said almost always and not just always is that there may be some cases when having two, or more, tables contain the same type of data would be a good idea. For instance, in the schedules example. You may want to keep all teacher's schedules data in the Schedules table but periodically move data older than a year out of that table into an ArchivedSchedules table. This second table may have pretty much the same structure as the Schedules table but separating the data this way would make sense because it would improve access performance.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I have a lot of different databases and tables that contain user information. I would like to write a query, that would find all the necessary information. So when I use "where" clause (e.g. where Email = 'Example#example.com', or where Name = 'Mister Holmes' etc), it should bring up the results I'm looking for and search from all the related databases and tables.
My idea is to make a new view, bring all the related tables in there, and then join the necessary columns somehow. Is that possible?
Can anyone please help?
I had the same problem. I just describe my way - Because I have many different databases with different storaged infos about users, I collect all of them with INSERT and every time I am looking for WHERE SOMETHING, I am running this:
truncate target table (which is already prepared with necessary colls like NAME, LOGIN, RIGHTS, APPS, NOTES, ...)
filling target table with data from VIEWs, which are specific for each db / apps / or user groups
This two points I stored in procedure. Maybe it is not quickest way, but searching and filtering above one static table is much more safe and less consuming then searching in twenty views.
But, be aware, I you are not alone DBA and you have collegues which are playing the role of administrating sql in your area, I think, this solution is not lucky.
Or do you have standard user informations in server_principals, server_role_members, database_principals, database_permissions, schemas, ... ?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Users can select dates from a calendar to block. If I store each selected date as a record/row in my Calendar table, then there would be lots of stored rows/records. Is there a more efficient (less processing) way of doing this?
It depends if the user is going to block the date for everyone or just for themselves:
If they are blocking the date for every user that views it then it would be a good idea to store this in the Calendar model table, as every user will need to load this each time they load the calendar.
Or
If each user is blocking the date so only they can see that it is blocked, it is better to store the data in either the User model table or else as an association between the user and the calendar. This depends on how your calendar model is set up. If you wanted, you could have a column in the user table that stores data that represents all the dates that are blocked for that user. This will prevent the large number of rows you are talking about. This could be done with a JSON column in the User table. You could also store the data of which dates are blocked as a relation between the user and the calendar by creating a UsersCalendar table.
With a more detailed question we could give you a more detailed answer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
For example, you have tables Users and Groups; a user can be member of many groups, and a group has many users.
So how would you name the table that connects them?
Should it be user_groups or group_members ?
Personally, I think the latter is better.
Though it depends. If I want to know the groups of a user, I think the former is better. If I want to know the members of a certain group, I think the latter is better. However, I think it's not right to create both table since they are the same.
See first reply from What should I name a table that maps two tables together?
Your question can be considered as duplicate, because already exist one with a good answer there.
And my personal answer for your question, I prefer to use a prefix for all many-to-many tables, example : MapGroupUser, where "Map" is the prefix. So, all tables of this particular type will be different from the others
I would like the table name to help me identify the tables from which it holds the data. Although group_members seems more logical, I would prefer users_groups as it clearly mentions the tables from which it holds data.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
A version control system compares the scripted definition of a table to the checked in state. So I guess many cvs will see column reordering of a table as a change.
Since tsql does not support to add a new column in the middle of a table and because in a relational DB the ordering should not matter, what are good practices for version control of table definitions if the column-order could change.
Sometimes you could need to redo a drop column in the middle of a table.
You should be storing scripts to setup your database in source control, not trying to have something reverse-engineer those scripts from the state of the database. Column-order then becomes a non-issue.
Specifically, I've seen two schemes that work well. In the first, each database schema update script is given a sequential number, and the database tracks which sequence number is the last applied. In the second, each database schema update script is given a UUID, and the database tracks all UUIDs that have been applied.
I would checkout the book Refactoring Databases for more details and examples of how to manage database changes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm working on a basic admin panel for a site of mine but have run into a problem. I haven't done much SQL so sorry if this is fairly basic knowledge.
The Site has a JS Slider which shows our sites best selling products currently (As seen here : http://www.theyard-store.co.uk/)
I created a form so I could easily update the slider, but I don't know the best way of linking it to the database.
I thought about just having a separate table for each product and a separate form then just use SQL UPDATE to do this.
Is this the best way of doing it? Is there more efficient methods?
"I thought about just having a separate table for each product "
No, seperate tables for each product is a nightmare...imagine a new product being added and you having to go through each line of code to refer to the new product table added.
My recommendation is to have a single product table...something simple like "Product_ID, Product_name, coupl other data points, etc.." as you product table. A second table (product_form?) can be created that refers to the product_ID in your product table and then store relevant data on your form information.
My preference is to never over-write data in your database either. If you include a 'status' or 'active_flag' column in this new product_form table, you can simply insert a new line and set the old line to inactive. This way you save all previous entries for the product_form record and can build a history/workflow/validation process.