Scenario:
I am creating a website for a checklist, it can be done/accessed by multiple users in the same time thus it needs certain fields to be editable, saveable and retrievable.
Dilemma:
The checklist has 212 entries, this means 212 rows. I have 5 columns that needs entries thus, 212x5. This means, I have to create 1060 columns to be able for me to code the website to do what I want it to do. 1060 columns on a table seems wrong and very tiring to use.
My Sample solution:
I would divide the 5 columns into 5 tables, making the date that the checklist was created as their primary key. I would then use this 5 tables for their corresponding columns thus reducing the number of columns per table to 212.
Is there anyway that I could reduce this? Sorry for the long post, any help would be appreciated.
**Edit: For some reason, I can't comment on any answers, says error on page. Nevertheless, I do appreciate everybody's answer; Yet I have 1 info that may change your answers. I have thought of making 5 columns instead of the obnoxious 1060, but doing that, I would need/The system would need to create 1 table per 1 worksheet and of course, over time, this would cause massive problems to the database.
Although still pretty huge, ah_hau's answer seems to be the smallest and easiest to handle. By using it, the system would create 217 entries per checklist, but will use 6-8 columns only. Thank you to everyone who shed light into this dillemma, I do hope that I see you guys again on my next question. Cheers!
There are different ways to do it, I'd just store a Json string per checklist. The Json string would be a Json array of object { checklistName, checklistValue, timestamp }. So, the database table would only have two columns { id, checklist }. This is on the minimum side, you might want to break it down to smaller Json objects and/or add more details to them.
looking thrrough all your requirements, thou you've ban the common 6 column setup, I'd still suggest you to use a similar setup.
try to have a table like this
id [bigInt] (PK,auto_incrment)
rowId [int] //checklist row id
columnId [int] //checklist column id
text [varchar/text]
create_date [Date]
create_time [Time]
Index
unique key chekcklist_cell (create_date, rowId, columnId)
depending on your preference, you could also split columnId field into 5 columns with name column1~5 to reduce the DB entry count. But i'd suggest using my setup as it seems like user will update your checklist 1 cell at a time (or multiple cell all around the list), which my schema will make more sense. Also this schema is very expandable and could easily add new fields to them. Last thing I could think of is that you doesn't have to lock the whole checklist while a user is only updating 1 cell. This helps speed up that concurrent access thing.
why not directly add 1 more column in your checklist table?
your table structure should look like
userid
entryid (value from 1-212)
col1_entry
col2_entry
col3_entry
col4_entry
col5_entry
Related
First, I am making a little raffle site. I have a grid of square buttons (all assigned a number) right now and I want to be able to toggle as many as I want, then send that info to my database that those squares are "taken".
Will I need to make a separate row for each square? Or is there some easier way to do this?
In the case that you want to query the database just when you click a button and not everytime you toggle a square, having a separate record for every number will be unnecessarily expensive. There are more elegant ways of achieving the same result.
I would instead suggest creating a record for individual person playing the raffle with a primary key of autoincrementing id so that you can easily identify a person. Each time a person flips the squares and hit submit, a query will be fired through php that will carry the values entered by that person which will be in form of 0s and 1s. If you have 9 squares for example, the user input will be something like 101011001. You can now save the record in form of < userid , raffleentry >. This structure will make it extremely easy for your query system to store the values as well as make out who won the raffle.
Note: You can also do some cheeky stuff and save the raffleentry as a decimal value by interpreting the raffle entry as a binary representation. hence you can save the entry as 345 instead of 101011001
EDIT: To answer OP's question in the comments
I have a primary key for my users, but I have at least 5 raffles that are going on at one time. Should I make 5 different raffleentry columns? Like raffleentry1, raffleentry2, etc
You can do that. But again theres a more elegant solution here. Make only a single column (integer) called raffleentrynumber this will take values 1-5. Now instead of creating primary key only on the userid, create it one composite (userid, raffleentrynumber). What this will do is preserve your primary key integrity constraint and also make your table much cleaner
Your table will look something like
USER_ID RAFFLEENTRYNUMBER TICKET
1 1 101010101
1 2 111100001
1 3 000000000
1 4 111111111
1 5 010101010
2 1 000011110
2 2 011110011
Yes. I would create a separate record for every number. I'd also create a second column indicating if they've been selected or not using 0's and 1's. (For example, 1 if it has or 0 if it has not). You can use SQL query statements through php to update these values.
I guess that title isn't very descriptive, so I will explain! I have table called users_favs where is stored all info about which posts user has liked, which post he has favourited and the same for comments. info there is stored as serealized array / or JSON who cares.
Question: What is better? Stay like this or to make 4 tables for each of the fields and store not in serealized version but like user_id => post_id???
What I think about second option is that after some time this field will be GIGANTIC. Also, I will need to make 4 queries (or with JOINS) to take all of the info from these tables.
Keeping it in 1 table means that you'll only need 1 table access and 0 joins to get all the data. While storing it in 4 tables, you'll need at least 1 table access and n-1 joins, when you need n fields of information. Your result set at the end of the query will probably be the same, so the amount of data send over the network is independent of your table structure.
I presume a scenario when you will have data for fav_categories and other columns are null. Similarly for columns fav_posts, liked_posts, liked_comments. So there is a high probability that in each row , only three columns will have data most of the time (id,user_id,any one of rest). If my assumptions are right and the use cases as well , then i would definitely go four four tables.
To add to above you can always choose from whether you want to make read-friendly or write-friendly.
I currently maintain a single DB table that has some info for images that are stored in a file system. This setup works well with the several hundred thousand photos I currently have recorded.
For a users default image I maintain a separate folder that contains the photo but this has become a maintenance nightmare. Should I create a second table that stores a reference to the default photo from table 1 or is it better to add a new field in table 1 that's a boolean I can set to indicate a default photo?
My table looks something like this:
image_table
id user_id file_name
1 6 xvy.jpeg
2 6 abc.jpeg
3 6 def.jpeg
Proposed solution:
image_table
id user_id file_name default
1 6 xvy.jpeg 0
2 6 abc.jpeg 1
3 6 def.jpeg 0
In this proposed solution it seems as though I would need to make two SQL calls to reset the default and then a second call to set a new default photo if a user changes it...
It is better to add new fields instead of add new tables, if the second table would have identical columns to the first if you went that approach.
Reasoning: If I need to get values from both tables, I would need to do a cumbersome UNION. What if you had three or more tables that all had the same kind of data, and I wanted all of them at once? It just gets clunkier and clunkier and more awkward to code against.
Well i can see you are using some SQL database but dont take me wrong why dont you try a NoSQL database such as MongoDB . I know creating a field as a flag or creating a new table doesnt seems to be a good design.
My table looks like this,
RangeId CellId Some Coulmns more
101 1
101 2
I ll get a list with [101,2],[101,1] now i have to swap cellId values in the above table. How to write an update query for this. I went through Swapping column values in MySQL but this swaps between two coulmns. Any suggestion..
EDIT: I am swapping the cells in my app and i ll get two cell ids. I have two just swap 2 with 1 and 1 with 2 and rest of the values in the rows remains the same
EDIT2: The table doesnt have any Id column nor a primary key.
With your table as currently stated you cannot really do as you wish as there is no unique way to identify rows. I advise that you step back and look at what you are trying to do as it feels like either a: it's not been thought through, or b: you've not given enough information for this to really be solved
If b:, please provide more information on this table and the tables it links to and precisely what you are trying to achieve (yes I know you want to swap 2 numeric values however without knowing more information about the tables / what can be used to select it is VERY hard to advise accurately)
note below was written for OPs original edit
This isn't a nice way to do it but it may get what you are after, it relies on ID being a PKID
http://sqlfiddle.com/#!2/0c48c/2
What would be the best MySQL type to use to store very long CSV data? say half a million integers of 5 digits or less?
Also, what would be the benefit/drawback of adding a new column to the table instead of adding a new value to the CSV string? Can a MySQL table even have half a million columns?
I would be updating the table either way, one 5 digit integer at a time, and I would need to search through either the CSV string or the columns a lot?
Basically what I'm doing is recording which of my users have voted for a certain idea so no one can vote more than once. There is not a set number of ideas however, it is constantly expanding, and I dont want to add anything to my already fairly big Users table.
Would it be better to create a new table for each idea that will be voted on?
What would be the fastest/least processing intensive route here?
The relationship between users and ideas they've voted on should be represented by a table with a column identifying the user and a column identifying the idea. When a user votes on an idea, you insert a row into this table. The column pair is the primary key of this table, which enforces uniqueness (preventing duplicate votes).
Instead of adding all votes for a user in one row, make one row per vote and user. The table then contain of two columns 1. the user and 2. the idea the user voted for. This solves your problem and also enables you to do more things easier in the future; eg. count number of votes for a certain idea.