I'm wondering what is the best way to store content edits in a MySQL database?
I was first going to do something like Current_COMMENT, First_COMMENT and have the original comment stored in first_COMMENT and the latest comment (one that I would display) to Current_COMMENT.
But then I realized it would be much better to store each commend edit so I could look back at all the revisions.
My question is, what is the best way to store this in the database? It would be nice if I could store a (almost)infinite amount of comment revisions.
Any help is much appreciated!
Use a column for create date, so you can utilize the history if need be. For the most recent comment, mark it with a flag column called current. A simple int will suffice: 1 for current, 0 for all others.
Related
I need to log every changes through the application. Every changes will be connected to specific user, but connection can be null as well (add new item by remote API).
Let's imagine that some user adds new item. Here my problem starts... :) I don't know, how to store it properly and also don't know right solution. My ideas:
1 MySQL record
id(bigint), created_at(timestamp), user(int), changes(json?/or something else?)
JSON would be like:
{
table_name: 'item_name',
id_item: 1,
note: '' // optional
}
I don't know if this method is right for this use case. When I am writing this, I am thinking about id as uuid not int. Could it be?
2 JSON
Save record by record to the json file and after some size create new one. Records would be the similar structure.
I really don't know what method is the best for this use case. I'll be appreciate for a bit help. Thank you. Have a nice day. ;)
What you are describing sounds similar to functionality provided by temporal tables, a feature built into recent versions of MariaDB. You may want to look into that before you start inventing your own audit logging.
I'm writing an application to allow users to create a Poll. They ask a question and set n number of predefined answers to the question. Other users can vote on the answers provided for that question.
Current structure
I have designed the database like this:
Storing the vote count
Current thinking is, I create a new column called vote_count on the link table and every time that answer gets voted, it updates the record.
This works. But is it right? I'm new to database systems, so I can't imagine I'm doing much right. What are some more efficient ways to achieve this?
As far as it goes yes that's OK. However these tables will be incomplete. When your second quiz is created, you'll have to extend the QUESTIONS table. If this second quiz's Q1 also has a yes/no answer, you're going to have to extend the LINK/VOTES table.
You also have to think about how it's going to be queried and design indexes to support those queries.
Cheers -
I want to create one database which can handle daily deals provided by partners.Also i want to design it in such way so that database it self will not allow duplicate data by using combination of lat-long, name & date-time. As for now i have one provider but in future i might get deals from 2-3 different partners.
Is one table is enough for above requirement which will handle all the data.
I will really apreciate any comments/ suggestions or hints to get me start or push in right direction. Any type of reference info.
Please let me know if need some more information or i am not clear about any point...
Regards,
K
I would at first put the partners in a separate table, to store all their information. Then, the deals only need a partnerid. It is unclear to me what these deals are, and if you may need a separate table with product information, so a deal is actually a link between a product and a provider, for a given period of time.
In that case, you need three tables at least to store just the deals, apart from any orders and other information you might need.
But if you start modeling, it is strongly advised that you do some reading about database normalization. It will give you a guide to what you should store in which table.
http://databases.about.com/od/specificproducts/a/normalization.htm
I would like to have questions marked as "Edited", but I dont know what the best way to do this would be.
Users post a question, people answer/comment on the question, and if necessary the user edits/updates the question (just like SO). I would like to note that the user edited the question, but I'm not sure of the best way to do this.
I was going to add a last_edited column in the table (because thats all thats really important to me), but I'm not sure if I should just split the edit times (and whatever else) into another table and record everytime the question gets edited.
EDIT: UIf I were to use a timestamp, what time would be used? Is there any way to insert a unix timestmap on update?
This depends on whether anyone (users or admins) ever cares about history of edits.
If they do, definitely split into another table
If all what you want is a mark Edited or not, you can just add a Timestamp column in the same table, populated to NULL by default, then populated by last update timestamp.
On the page if its populated then display its value, otherwise don't display the Edited icon/symbol.
If you only care about when the most recent update occurred, add a timestamp column in the same table.
If you'd like to keep track of every edit that's occurred, create a separate table that contains question_id and the timestamp.
Depending on how you're processing your date/time data, you can either store the unix time stamp (fieldname = unix_timestamp(now())), or as a regular mysql datetime field (fieldname=now()).
If you're going to do data sorting/filtering based on dates/times in mysql, then use the native datetime type so you can take direct advantage of all of mysql's date&time processing functions. If you're going to do most of the processing in your application, a unix timestamp tends to be more portable than a formatted date/time string.
As for the table structure, the simplest way to track edits is a pair of fields (lastedited, and lasteditor). If you want to keep a full list of editors and times, then you'll need a seperate table. If you're keeping track of the changes, then the versioning/trakcing information can go into the same table.
So on my older work, I had always used the 'text' data type to store items, like so:
0=4151:54;1=995:5000;2=521:1;
So basically: slot=item:amount;
I've been looking into finding the best ways of storing information in a sql database, and everywhere i go, it says that using text is a big performance hit.
I was thinking of doing something else, like having a table with the following columns:
id, owner_id, slot_id, item_id, amount
Where as now i can just insert a row for each item a character allocates. But i have no clue how to save them, since the slot's item can change, etc. A character has 28 inventory slots, and 500 bank slots, should i insert them all at registration? or is there a smarter way to save the items
Yes use that structure. Using text to store relational data defeats the purpose of a relational database.
I don't see what you mean by insert them all at registration. Can you not insert them as you need to?
Edit
Based on your previous comment I would recommend only inserting a slot as it is needed (if I understand your problem). It may be an idea to keep the ID of the slot in the application, if need be.
If I understand you correctly, and that the slot's item can change, then you want to further abstract the mapping between item_id and the item:
entry_tbl.item_id->item_rel_realitems_tbl.real_id->items_tbl
This way, all entries with an itemid point to a table that maps those ids to a mutable item. When you UPDATE an item in 'items_tbl' then the mapping automatically updates the entry_tbl.
Another JOIN is needed however. I would also use stored procedures in any case to abstract the mechanism from semantics.
I am not sure I understand the wording of your question however.