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.
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 2 years ago.
Improve this question
I am a noob in DBMS. I am developing a project which has multiple readers and writers.
Here are the steps of the project.
User Logins
Makes changes
Then clicks submit
Admins review the changes and merges with the main DB.
So, I thought let's use a transaction for each user when they login to my project. Because the transaction takes a snapshot and commits data if all the queries are executed without any error.
If two users want to write in the same row then the transaction throws an error that is required for the project.
Now my question is if such an error occurs then I want only that query to fail I still want the transaction to continue if it has no error.
You are trying to use the concept of a database transaction in a wrong way. Database transactions should be very short (sub-second) and never involve user interaction. The idea is to group statements that belong together so that either all of them succeed or all fail.
What you want to do is application logic and should be handled by the application. That doesn't mean that you cannot use the database. For example, your table could have a column that persists the status (entered by client, approved, ...).
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 7 years ago.
Improve this question
Apologies in advance if this is a stupid question. I've more or less just started learning how to use SQL.
I'm making a website, the website stores main accounts, each having many sub-accounts associated with them. Each sub-account has a few thousand records in various tables associated with it.
My question is to do with the conventional usage of databases. Is it better to use a database per main account with everything associated with it stored in the same place, store everything in one database, or an amalgamation of both?
Some insight would be much appreciated.
Will you need to access more than one of these databases at the same time? If so put them all in one. You will not like the amount of effort and cost 'joining' them back together to do a query. On top of that, every database you have needs to be managed, and should you need to transfer data between them that can get painful as well.
Segregating data by database is a last resort.
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 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.
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 8 years ago.
Improve this question
How could I get the changes (data) in a view between a certain period of time. Changes like new rows, updated rows or deleted rows. I am making a stored proc which has to detect the changes in a huge view and then sync them with another table on daily basis. I dont want to to scan all rows when I know the changed rows will be less than 1% daily.
Thanks.
The view is going to change when the underlying data changes. You need to detect changes in the columns in the tables that are in the view - you will probably need triggers on that column that will fire a stored procedure that reconstructs the SELECT query the view is using, and then update the other table as necessary.