I have a database with the following table.
Entity (ID, EntityType),
Tickets (TicketId, ..., (TicketId refers Entity (ID)),
Contacts (ContactId, ..., (ContactId refers Entity (ID)).
I want to duplicate Ticket data in another table,
TicketsDup (TicketID, ...).
In TicketsDup table TicketID should refer Entity table or Tickets table?
The point of TicketsDup is to store only active tickets. So inactive tickets will be deleted from TicketsDup table. But will still be stored in Tickets Table. The user can mark a ticket as active. In which case the ticket has to be inserted into TicketsDup table. Also modified time has to be updated in Tickets table. This is where my concern is. Mysql locks parent rows from getting updated when a child row is being inserted. This causes deadlock. Is it wrong to refer Entity table for TicketsDup table? I hope the question is not vague.
I would suggest to write every new ticket to the STORE table and then duplicate it in the ACTIVE table. So you don't get any problems with the id field.
If the ticket in the ACTIVE table is closed you copy the data into the STORE table and remove it from the active table.
If you search for an ticket you search the ACTIVE table first and then in the STORE table.
If a ticket in the STORE table is marked for active you copy it back to the ACTIVE table.
But if you don't have that many tickets I would stick to one table only. I have 6 years of tickets in one table and its not getting slower. Just mark them active and nonactive. I don't even delete a ticket just mark it deleted.
Related
I'm a beginner at MySQL.
I have a table with 160rows .
I need to keep tracking this table everytime someone make change to all row ,
example
tabelname = customer
id
user_id
name
lastname
datebirth
accupation
spouse
etc...
etc..
until 160 rows in total
When someone changes a record, let say datebirth, I need all detail record in the history table.
When someone changes 10times, I need all the records to change, so I have 10 save records on history tables.
You can maintain another table for history. Whenever any update happen in base table you just need to copy current row to history table and you can additionally maintain user_id (user who updated row) and timestamp (time when update occurred). This way you can fetch the history of the row with group by operation on customer_id, time etc.
For Implementation you can follow this approach - https://dev.to/zhiyueyi/design-a-table-to-keep-historical-changes-in-database-10fn
for more info - 1-> SQL history table design
2-> how to have a history of the Sql table column.?
3-> How to store historical records in a history table in SQL Server
I'm trying to implement a flight booking system, and the use case is as follow:
A registered customer should be able to buy several tickets, not only for himself, and for each ticket the passenger info would be recorded.
In the database design, I have two tables -- a ticket table, and a purchase table. Tuples in the ticket table records only information with the flight and the passenger, and each ticket has a unique ticketID as primary key. Inside the purchase table, it has a foreign key reference to the ticket table, and has attributes that indicate which registered use this purchase record belongs to.
Now, suppose I have several tuples of passenger data sent to the server, the first thing I should do is to insert new tickets, and then I could perform insertion on the purchase table indicates the relation between each tickets and the person who bought the tickets. Notice that the new records in the purchase table would have ticket_ids which were just created by new tickets.
My confusion is: how do I implement this within one operation as a whole? ** In the purchase table, I would also give the tuples that are created by the same customer in the same transaction an ID, indicates that those tickets belongs to the same purchase records. ** Could I achieve this using a stored procedure? I feel like the passing of data is tricky, since I'm very new to stored procedure, etc.
I have records table with booking records info (8 columns). And I want to add to a record information about extra services that a client booked. I created extra_services table, but how can I specify multiple extra services to one record in records table?
If I add 9th column with just one id of extra service then there will be redundancy problem.
It depends a little on what is the content of the extra_services table. If it does contain a set of extra services that can be booked you need a table to cross reference the bookings with the extra_services.
If on the other hand you are storing the booked extra services belonging to the record you can just use a ForeignKey field to the index of the records table in the extra_services table, that way you can track which records in extra_services belong the booking record.
In Microsoft Access I have three tables: order table, customer table and product table. My order table pulls in both customer contact and product information. Every now and then I need to update either the customer address. When doing so, I only want the new address to appear on future orders. I don't want Access to update previous orders with an address that was not originally affiliated with that order. I also want to maintain a list of active and past addresses on the customer list. Please advise on the best ways for setting up the customer table and how to retain customer contact information on the order table.
To do this you need to take the customer address out of the Customer table and keep it in a separate CustomerAddress table. This new table has a primary key (of course), a foreign key back to the Customer table, all the address fields that you want to maintain history of and a Current flag (Yes/No). Your Order table then points directly to the CustomerAddress table instead of the Customer table (you can get from Order to Customer because of the FK link on CustomerAddress to Customer). Now your fun starts! You have to maintain your CustomerAddress table in such a way that for each Customer ID you should only have one Address record where Current is True.
The other alternative is to not have a Current flag on the CustomerAddress table, but instead have a CurrentAddress field in your Customer table - this ensures that only one Address can ever be the current one for a Customer. However you can't enforce both the CurrentAddress integrity and the CustomerAddress foreign key - you can't set the value of CurrentAddress until you've added the Address record, so Customer record has to be able to exist with NULL CurrentAddress (although I suppose you could have a dummy 'Not set' CustomerAddress record).
The simple method is to store the current customer information with the order.
The extended method is to store the customer table(s) as temporal tables, either using a custom method or a native as - for example - offered by the newest versions of SQL Server. Look up the term Temporal database for more information.
I had to implement the following into my database:
The activities that users engage in. Each activity can have a name with up to 80 characters, and only distinct activities should be stored. That is, if two different users like “Swimming”, then the activity “Swimming” should only be stored once as a string.
Which activities each individual user engages in. Note that a user can have more than one hobby!
So I have to implement tables for this purpose and I must also make any modifications to existing tables if and as required and implement any keys and foreign key relationships needed.
All this must be stored with minimal amount of storage, i.e., you must choose the appropriate data types from the MySQL manual. You may assume that new activities will be added frequently, that activities will almost never be removed, and that the total number of distinct activities may reach 100,000.
So I already have a 'User' table with 'user_id' as my primary key.
MY SOLUTION TO THIS:
Create a table called 'Activities' and have 'activity_id' as PK (mediumint(5) ) and 'activity' as storing hobbies (varchar(80)) then I can create another table called 'Link' and use the 'user_id' FK from user table and the 'activity_id' FK from the 'Activities' table to show user with the activities that they like to do.
Is my approach to this question right? Is there another way I can do this to make it more efficient?
How would I show if one user pursues more than one activity in the foreign key table 'Link'?
Your idea is the correct, and only(?) way.. it's called a many to many relationship.
Just to reiterate what you're proposing is that you'll have a user table, and this will have a userid, then an activity table with an activityid.
To form the relationship you'll have a 3rd table, which for performance sake doesn't require a primary key however you should index both columns (userid and activityid)
In your logic when someone enters an activity name, pull all records from the activity table, check whether entered value exists, if not add to table and get back the new activityid and then add an entry to the user_activity table linking the activityid to the userid.
If it already exists just add an entry linking that activity id to the userid.
So your approach is right, the final question just indicates you should google for 'many to many' relationships for some more info if needed.