Before you read on I just want to make something perfectly clear, Im not looking for someone to code this for me, I just need to know whether it would be possible for me to do this, as I don't have that long to spend on this part of the task, and I thought it'd be best to ask the experts/guys on Stackoverflow.
So my question is:
I have a number of questionnaires, which will be completed by participants, since the answers are strings, I was wondering whether it would be possible to store these answers as integers, for example, you'd have:
1 ="Never True" 2="Rarely True" 3="Sometime true" 4="Often True" 5="Very Often True". I want to store only the numbers, I was just wondering whether that would be possible.
Thank You.
Finished
I think before I had worded the question quite badly, my bad. However, I did manage to complete that part, I stored the values in the database, which I assigned to each of the answers. Also as #octern had mentioned to create a code, this was also very handy, so thank you.
I appreciate all the responses, and your time for dealing with this question.
You can. If your participants are using an HTML form to submit their answers, just set the VALUE attribute of the form element to the numeric code for the answer, and that's what will go in your database.
Just make very, very sure that you create a codebook so you can figure out which number corresponds to which answer in the future! You don't want to rely on parsing the web page, which may have changed over time.
Yes, you can store integers in a database. And obviously you can assign your own meaning to those integers.
Yes you can do that. Alternatively, You can create a table called "possible_answers" for example with id as the primary key and text as the question. The table that stores the answers to a question can now have a foreign key to the possible_answers table to make sure the integer saved is always valid.
There are two basic ways to store the values as integers in a relatively easy way to read and understand.
The simplest way is to store them as an ENUM because the value stored in the row is actually an index to the list of possibilities in the ENUM declaration. The problem with ENUMs is the list of possible answers must be known in advance, and the list needs to remain relatively static unless you like taking outages to change the table's structure each time you want to maintain that list.
The most flexible way is to create a table with an ID column (typically an auto_increment or serial of some sort) and the label used for that number. Then, the original table simply refers to the ID column in the "other" table. This is commonly referred to as a foreign key reference.
In MySQL, the performance of ENUMs versus foreign key references is nearly identical.
Yes, you can certainly store integers in a database. Keep in mind that if you do this, you will need to "translate" those integers into the actual answers in your application, probably with a switch statement.
Related
I have a SQL database of individuals, identified by a unique key. I will need to record whether they have siblings, what gender they are, whether they are older or younger than the index individual and whether they are affected by a particular disorder. For these purposes, it does not matter whether their siblings are in the database or not, but the solution should work for the majority of individuals whose siblings aren't. My question: what is the most efficient way to store this kind of information? Do I create another table, or keep it in the same database as a serialised array, or some other trivial way I fear I am overlooking?
Define efficient first.
Keeping siblings info as a serialized array (in a separate field) will work only if you are not going to perform any SQL operations over this field. For example, you are not going to find the person who has the biggest number of siblings.
Another table is needed if your application really has a 'Sibling' entity. If siblings info is just an attribute of an individual (like a first name, just more complex in structure), you are ok to keep it serialized in a single column.
In general I would tend to say: Never put a serialized array into the database. There is always a better solution.
How this solution looks heavily depends on the exact data you want to store and how you are going to access the data. Maybe you should add another table for each type of data, maybe you should add some kind of has-and-belongs-to-many table.
Sorry that there is no general answer to your question, but there is no omnipotent solution.
I have to create unique codes for each "company" in my database.
The only way I see this to be possible is to create a random number with rand() and then check if the number exists for this "company" in the DB, if it does recreate.
My question is: Is there not a better way to do this - a more efficient way. As if I am creating 10 000 codes and there are already 500 000 in the DB it's going to get progressively slower and slower.
Any ideas or tips on perhaps a better way to do it?
EDIT:
Sorry perhaps I can explain better. The codes will not all be generated at the same time, they can be created once a day/month/year whenever.
Also, I need to be able to define the characters of the codes for example, alpha numberic or numbers only
I recommend you to use "Universally Unique Identifier": http://en.wikipedia.org/wiki/Universally_unique_identifier to generate your random codes for each company. In this way you can avoid checking your database for duplicates:
Anyone can create a UUID and use it to identify something with
reasonable confidence that the same identifier will never be
unintentionally created by anyone to identify something else.
Information labeled with UUIDs can therefore be later combined into a
single database without needing to resolve identifier (ID) conflicts.
In PHP you can use function uniqid for this purpose: http://es1.php.net/manual/en/function.uniqid.php
MySQL's UUID Function should help. http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#function_uuid
INSERT INTO table (col1,col2)VALUES(UUID(), "someValue")
If the codes are just integers then use autoincrement or get the current max value and start incrementing it
Today, I've had some debate with my colleague about choosing data types in our projects.
We're web developers and we code back-end in PHP, and for database we use mySQL.
So, I went on internet a bit, and they don't recommend ENUM data type for various reasons (also I've read here on SO that this is not recommended) - For ENUM('yes','no') for example you should use tinyint(1) .
If ENUMs are bad and should be avoided, why does vBulletin for example, uses them?
Why use them at all when you can use VARCHAR, TEXT and so on and enforce use of 1 of 2 possible values in PHP.
Thank you for your answers.
Enums aren't ideal, but they are waaaay better than your alternative suggestion of using a VARCHAR and enforcing one of a few possible values!
Enums store their data as a numeric value. This is ideal for storing a field with a limited set of possible values such as 'yes' or 'no', because it uses the minimum amount of space, and gives the quickest possible access, especially for searches.
Where enums fall over is if you later need to add additional values to the list. Let's say you need to have 'maybe' as well as 'yes' or 'no'. Because it's stored in an enum, this change requires a database change. This is a bad thing for several reasons - for example, if you have a large data set, it can take a significant amount of time to rebuild the table.
The solution to this is to use a related table which stores a list of possible values, and your original field would now simply contain an ID reference to your new table, and queries would make a join to the lookup table to get the string value. This is called "normalisation" and is considered good database practice. It's a classic relational database scenario to have a large number of these lookup tables.
Obviously, if you care fairly sure that the field will never store anything other than 'yes' or 'no', then it can be overkill to have a whole extra table for it and an enum may be appropriate.
Some database products do not even provide an enum data type, so if you're using these DBs, you are forced to use the lookup table solution (or just a simple numeric field, and map the values in your application).
What is never appropriate in this situation is to use an actual string value in the table. This is considered extremely poor practice.
VARCHARS take up much more disk space than the numeric values used by an enum. They are also slower to read, and slower to look up in a query. In addition, they remove the enforcement of fixed values provided by enum. This means that a bug in your program could result in invalid values going into the data, as could an inadvertant update using PHPMyAdmin or a similar tool.
I hope that helps.
I have an idea. It might be bad, for reasons not known by me, but I would really appreciate your feedback on this!
We've been using Session ID's in a PHP project. And for the first time in 4 years, a duplicate sessionid was generated. Luckily enough I randomly decided to go looking through the Customers Table because I was bored and noticed there was a duplicate entry in the sessionid column and changed it, and references to it, before any real problems occured.
Which led (or lead?) me to ask myself this question:
Basically, any type of ID, be it a session id, uuid or guid can eventually be duplicated because the length of them is not infinite. So then I got thinking, because we never want this to happen again.
I thought, What if we use a combination of date and time, as an identifier? This wouldn't be "random", but it would solve the duplication issue. For example:
14th of May 2011 04:36:05PM
If used as an identifier, could be changed to:
14052011163605
The reason this form of ID will never become duplicated is because no date, combined with time in the future will ever be the same as one in the past, or present.
And since, in our case, these ID's are not meant to be seen by anybody, there's no reason for it to be random, is there?
I'd love to hear your thoughts on this, and, how you approach situations like this. What's your best method of generating [practically] unique ID'S?
The reason this form of ID will never become duplicated is because no date, combined with time in the future will ever be the same as one in the past, or present.
If you only had one user, this would be true.
UUID / GUIDs are very large (larger than the count of particles in visible universe)
your date/time solution will fail on high loads. what happens when i need 100+ new ids per second ?
Why not just make your session ID column a unique column, and then generate a new session ID if you get a constraint violation error? That way the database will find this problem for you in basically the same way that you did (and as a bonus, it can fix it too).
UUIDs are already generated based on nanosecond intervals of time (see this wikipeida article). If you are using PHP, I'd suggest this page to take a look at how to generate the different versions, depending on your use:
http://php.net/manual/en/function.uniqid.php
The reason you can't guarantee uniqueness is that you have to eventually pick a size limit for the actual string/variable containing your UUID, so there is always the potential for a duplicate. Given the number of possibilities for a UUID, though, this should be practically impossible.
I agree with the other posters... this probably shouldn't ever happen. How are you actually generating unique IDs? Are you sure your code is properly creating them?
Users can do advanced searches (they are many possible parameters):
/search/?query=toto&topic=12&minimumPrice=0&maximumPrice=1000
I would like to store the search parameters (after the /search/?) for an email alert.
I have 2 possibilites:
Storing the raw request (query=toto&topicId=12&minimumPrice=0&maximumPrice=1000) in a table with a structure like id, parameters.
Storing the request in a structured table id, query, topicId, minimumPrice, maximumPrice, etc.
Each solution has its pros and cons. Of course the solution 2 is the cleaner, but is it really worth the (over)effort?
If you already have implemented such a solution and have experienced the maintenance of it, what is the best solution?
The better solution should be the best for each dimension:
Rigidity
Fragility
Viscosity
Performance
Daniel's solution is likely to be the cleanest solution, but I get your point about performance. I'm not very familiar with PHP, but there should be some db abstraction library that takes care relations and multiple inserts so that you get the best performance, right? I only mention it because there may not be a real performance issue. DO you have load tests that point to an issue perhaps?
Anyway, if it is between your original 2 solutions, I would have to select the first. Having a table with column names (like your solution #2) is just asking for trouble. If you add new params, you have to modify the table columns. And there is the ever present issue of "what do we put to indicate not selected vs left empty?"
So I don't agree that solution 2 is cleaner.
You could have a table consisting of three columns: search_id, key, value with the two first being the primary key. This way you can reconstruct a particular search if you have the ID of a saved search. This also allows you to expand with additional search keywords without having to actually modify your table.
If you wish, you can also have key be a foreign key to another table containing valid search terms to ensure integrity. Whether you want to do that depends on your specific needs though.
Well that's completely dependent on what you want to do with the data. For the PHP part, you need to process it anyway, either on insertion or selection time.
For really large number of parameters you may save some time with the 1st on the database management/maintenance, since you don't need to change anything about your database scheme.
Daniel's answer is a generic solution, but if you consider performance an issue, you may end up doing too many inserts on the database side for a single search (one for each parameter). Too many inserts is a common source of performance problems.
You know your resources.