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 last month.
Improve this question
I have a SQL table Infos that stores some user information, the user can update his data but needs Administrator validation first,
the primary key of Infos is the referenced a lot in some others tables
Wy question is where chould I store the pending information that need validation ?
Is it a good idea to store them as JSON in a column ?
Treat this as a data modeling question. If the user information requires validation before it can be used in the application, introduce a Infos_UpdateRequest table or somesuch, that the administrator can use, and if approved copy the values from there to Infos.
You could create an Infos_Pending table with the same schema as Infos and the primary key being also a foreign key to Infos. So, your admins could load the pending records:
approval would first update the Infos record with the Infos_Pending values and then delete the Infos_Pending record
rejection would simply remove the Infos_Pending record
I would look at adding a pending approval and is active column to your table.
It would then be easy to identify which of your rows should be displayed. You could even keep older rows around for undo/history purposes.
This would mean you'd need to make changes to the sprocs/code used at your display layer, though.
I would suggest not using json or xml unless it's a situation where you always intend to chnage the entire set of values in contains.
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 days ago.
Improve this question
I have a SQL Server table. I need to keep track of 3 columns in that table. Whenever a change happens in one of those columns, the historic information present in that column needs to be moved to a separate column. Every time the change happened, the history column should keep track of all the changes that are being done on that column. May I know how to implement this process?
Example;
ORIGINAL TABLE VIEW:
enter image description here
CHANGE1 TABLE VIEW:
enter image description here
CHANGE2 TABLE VIEW:
enter image description here
CHANGE3 TABLE VIEW:
enter image description here
I read few docs online and they said that I need to enable track changes of SQL database and establish track changes on the table that I need to work with. After that I do not know what to do.
Do I need to write a code that concatenates the data present in the original columns to HIST columns? If so, How can I do it when the changes happen at random point of day? (If I follow this, is there a point to enable change tracking?)
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 last year.
Improve this question
I'm redesigning our service app, and getting rid of some really awful schema problems while I'm at it. Trying to build the replacement with best practices as much as possible.
I'm having a company table rather than just customer, as it's often useful to identify companies that are not customers (suppliers, contractors, etc etc). I'm trying to decide whether it's better to simply include a boolean field represented in the relevant part of the app by a checkbox that identifies relevant companies as customers (which would become uneditable once the customer has services attached to them), or if I should, instead, have a separate table that's basically just a single field referencing the Company ID that is in turn referenced by any child records.
This similar question asks about records that can be one of several subtypes. While the question is materially different (every policy seems to be only one of the potential subtypes, whereas Companies can be any or all of Customer/Supplier/Contractor etc) its similarity combined with the fact that it has multiple conflicting answers raises the possibility that there is no industry-wide consensus, so:
Is there an established best practice here? I'm not immediately seeing any reasons that other fields should be included in the prospective Customer table, but I'm open to the idea that there might... is that a good enough reason to go with B? Or is this a clear YMMV situation, where both options have benefits, either being equally valid?
I should, instead, have a separate table that's basically just a single field referencing the Company ID that is in turn referenced by any child records.
There are probably several attributes that apply to a customer that don't apply to a non-customer Company, so CompanyID probably won't end up being the only attribute of Customer.
So if that's the case, the clear choice is to have a separate Customer table.
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 implementing a seat booking application. I have a problem. There is a booking table. If two users try to book a same seat exact same time it will be a problem. How can I overcome this problem. I am using Java 8 and PostgreSQL.
A database system is designed to handle concurrent queries like in your situation by itself.
You however need to make sure, that a seat can only be booked once.
Solution #1 If you insert a new entry in the booking table for each booked seat
INSERT INTO booking (booking_id, seat_id, customer_id)
SELECT ?,?,?
WHERE NOT EXISTS (SELECT seat_id FROM booking WHERE seat_id=?)
This solution will check if there is already a booking entry in the database with the seat_id you are trying to book. This can be also achieved by putting an unique constraint on the seat_id attribute in your table. However in this case your query will fail with an error - since the unique constraint is violated when inserting a duplicated value - while in the solution above the query will execute sucessfully and just not insert any value. This solution is prefered.
Solution #2 If you have one row for every seat in your database and just need to update if its booked
UPDATE booking
SET booking_id=?, booked=true
WHERE seat_id=? AND booked = false
Depending on your JDBC library you are able to replace the ? with your real values.
The database system will handle concurrent queries and only allow one query to pass.
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 6 years ago.
Improve this question
For background, my situation is I have a database that is missing a lot of foreign key relationships. One in particular, let's call it Orders, which represents orders with a composite primary key of OrderID and LocationID. The other table we'll call OrderDetails which has an OrderID but no LocationID. In reality, it is impossible to have an order in two locations at once, so it was assumed that there was no need to have LocationID in the details table. I didn't design it, and I can't change that.
We also have to work under the assumption there will be no support to add location id to the details table for various reasons. We are also working with Oracle and a high volume database with many concurrent users in many locations. Finally, there will be minimal time to change any applications that use this table.
So my question is: is this solution is feasible, or is there anything else I should try?
Say I create an intersection table, for lack of a better name AllOrders or whatever with primary key OrderID. Now we link Order.OrderID to AllOrders.OrderID and link OrderDetails.OrderID to AllOrders.OrderID. Would it be reasonable then to fill in AllOrders via a trigger on each insert to Orders to enforce the integrity? I am assuming all applications are inserting details after orders or the changes to enforce would be minimal and allowed.
Are there any better solutions? I understand we would do this differently if in charge of designing or given more leeway for fixing, but I'm trying to make the most given the constraints.
Edit --
To clarify what I am looking to accomplish, I want to treat all orders with the same ID as an equivalence class modulo location and ensure that if any order is deleted it requires all orders with the same id deleted and all child order details to be deleted. With primary importance of no orphan details. This has to be done with minimal application changes if possible and no redesign of existing tables if possible.
Create a new table to handle the mapping going forward.
Table: Tb_order_orderdetails
Columns: OrderID, LocationID, OrderDetailsID
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 last year.
Improve this question
I want to add an audit trail for our system so when any Add/Delete/Update operation happen i will log it, with the following info:-
the CRUD operation type. is it add, delete or update.
the record ID which have been modified.
Date and time.
Now i found two approaches to follow; either to have a single audit trail table with the following fields:-
ID .such as 123445.
CRUD_description. Such as Delete
Record_ID. Such as Qaeop12771
Date. Such as 1june2O13
Or to have two tables one for a lookup table for the CRUD operation such as
CRUD_ID. such as 3.
CRUD_Description.such as Delete.
And then the Audit trial will reference the above table:-
ID. such as 123445.
CRUD_ID (this will be a foreign key to the CRUD table) such as 3.
Record_ID. Such as Qaeop12771
Date. Such as 1june2O13
So which approach is better ??
Second question If i will follow the second approach . Then is it preferred to use the CRUD_ID inside my code for example if the oprration is delete i might have my code look like:-
Inset into audit_trail (ID, CRUD_ID, Record_ID, Date) values ( 123445, 3,12771,1june2O13) //CRUID 3 represents delete operation.
Best Regards
From the viewpoint of database design (ignoring the database features and the application architecture ) I will prefer having a table for audit trail (change history) having changes per Entity and per field by implementing a flat table called Trail_History with no foreign key to any table, columns will be:
UserCode: Application user unique identifier representing who made the change. (mandatory)
TransactionCode: Any CRUD operation will need to have a unique transaction code (like GUID) (mandatory)
ChangeDate: Transaction date. (mandatory)
EntityName: Entity (table) that is being manipulated.(mandatory)
ObjectId: Entity that is being manipulated primary key.
FieldName: Entity field name.
OldValue: Entity field old value.
NewValue: Entity field new value
OperationType: CRUD operation discriminator. (mandatory)
Having this approach Any entity (table) could be traced Reports will be readableOnly changes will be logged. Transaction code will be the key point to detect changes by a single action and second question will be answered.
Hope be helpful.
Really the two approaches are prety much the same.
The seond one will be slighty more efficient but less flexible in the sense that if you need a new audit action you need to insert a new record in the type table.
The question how much information you need to audit is more interesting. Because say three users updated the record after eachother you still do not know who changed what in your design.