Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have just started PHP programming and have the following scenario;
My contact list is saved in mysql database (Fname, Lname, phone) = done
Take user input as imagining it taking from a mobile keypad .i.e. 'abc' corresponds to 1, 'def corresponds to 2 etc.
Let's say user enters "738"...this would correspond to 'PET' and so will 'REU'.
What the php code is suppose to do is get the user input in the form of digits and search through the mysql database going through the last name to see if it corresponds to any of the name and finally list those contact(s). However, since 'SET' is also a valid combination of 738 BUT if it does not exist in the database, it will not get displayed.
Question: how can i take the input in digits and generate all possible combination to match against the database? I guess i will have to use arrays to store the mobile keypad mapping and somehow do the permutations stuff.
Any help will be appreciated.
I would love to hear more about the use case where this is still worth programming in 2014.
If you really wanted to do this, you COULD enumerate all the possibilities and search that way, such as:
222 = AAA, AAB, AAC, ABA, ABB, ABC, ACA, ACB, ACC, BAA, BAB, BAC, BBA, BBB, BBC, BCA, BCB, BCC, CAA, CAB, CAC, CBA, CBB, CBC, CCA, CCB, CCC
Which is 3 cubed (27) possibilities.
However if you have 7 numbers you have 3^7th, or 2187 permutations, which is going to be an ungodly OR LIKE 'AAAAAAA%' chain.
However this method is backwards. What you should do is add a mobile-keypad-name for any name you want to search with this method, and pre-populate it with the representative digits- there will only be one possibility per name.
The SQL lookup is then a straight shot:
WHERE mobile-keypad-name = "2222222";
Related
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 5 years ago.
Improve this question
I am building a mysql database to store golf scores.
I am not sure on the best approach to store the round information.
Each round is made up of either 9 or 18 holes and for each hole I need to store
Hole id
Number of shots
Stableford points
Green in regulation
Fairway hit
Number of putts
Number of penalty shots
My question is should I have one huge table, that stores all of this. Like a rounds table. and have the above 7 fields 18 times for each hole.
Or should I have a smaller rounds table that just contains the date played etc and then another table such as scores that just has the 7 fields, and have multiple rows in that table to make up the complete round?
I guess I am asking in terms of which would perform better and which is the better design?
Thanks
Definitely two tables. First, let's name it rounds will contain data relevant to round itself, such as date, id of the golf terrain etc. The other, let's name it hole, will have 7 aforementioned fields, together with round_id field that will reference round that particular hole belongs to.
Main benefits are clearer design and avoidance of redundant data. If you keep everything in one huge table, each row would need to contain not just fields relevant to the single hole, but also fields relevant to the whole round (date, id of the terrain..) -> same data in many rows, unnecessary. What if you mistakenly enter wrong date? You would have to change it in all 9 to 18 rows instead of only one.
See also:
Normalization in MySQL
Database normalization
Divide your information as much as possible. Otherwise you'll face alot of redundant data.
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
I am working on a database project where one of the requirements is that we must have 100,000 tuples of data. We originally were looking for general population data where each individual is represented by a tuple, but we quickly found out that sort of data isn't really available. No worries, we can create our own data!
So basically I need to write a basic script to just iterate through every tuple and insert basic stuff, like an ID(Just number them 1-100000), a set of random initials, a random income, and a random occupation from a list of 6 or so. Is this possible in mysql? I am really not excited about writing 100000 INSERT commands
Something like this:
for i in range(1, 1000000)
initials = ?
income = ?
occupation = ?
sql = "insert into t(initials, income, occupation) values ('{0}', {1}, '{2}')".format(initials, income, occupation)
curs.execute(sql)
I'm not sure what values you want for the various fields. You can create lists of acceptable values and then use random() to choose from a list . . . or use random() to generate a numeric value.
It will take a little time to insert 1,000,000 rows. If this is an issue, write the data to a file and use load data infile.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Say I have a MySQL table like the one below with a list of names in an organisation, and IDs for each.
id name
1 John Doe
2 Richard Smith
3 Jane Market
... ...
Given user will query for the person's first and/or last name (with the possibility of typos and nicknames used) and php should return the closest match to their query.
For example, if a user enters "ricky" (nickname for Richard), it should return the ID for Richard Smith.
For nicknames, you have to create a separate MySQL table, with lookups (Many-to-One relationship).
For typos, you will have to loop all of your names and compare them to what the user has entered using the levenshtein function, or the similar_text function. The User Contributed Notes will help.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
most likely a clueless question but I would like to start off on the good foot:
Despite trying my best, I have actually never really learned to program and I'm kind of "learning as I go" so please excuse me if this seems very obvious to you...
It's more of a suggestion and feedback kind of question rather than pure programming.
My situation is the following:
I'm building a racing game that would receive various inputs from a number of users (through a php website), I am storing that information in a MySQL database, and once a week I would like to process all that information to generate "lap times", which will then create a race (my "output").
Not taking into account the various methods of calculating that output, I need to do two important things which I'm not sure how to begin with at all :
1) Storing the race information for every user (lap time per lap, fastest lap, race position per lap, race position at end of race, award points depending on the position).
Where and how should I optimally store those informations ?
I have created a race DB with a unique identifier that auto increments, I'm thinking I will generate 1 set of data for each race, so should I store all the information pertaining to that race in there ?
Would I then create a data row (with type time?) for the lap time informations (1 row for lap1, 1 row for fastest, etc... ?)? But how would I know which user (I have a unique userID for each) did which lap (how would I assign the userID to the lap time)?
2) At the end of the race I need to award points depending on race position at the end, should I just compare total lap times (additional row?) and sort by lowest first ? The points data would be stored in the user DB ?
I appreciate any input you might have for the modeling of this project !
Drop every lap_round, lap_time and position in the DB and add a user_id and a race_id.
Afterwards query the laps. That way you can tell which is fastest overall, fastest per user, time per lap and much more.
To get the position query the db for the last lap. It holds its position.
Points are user based, so put them in the user table. Just add. But if you want to tell how many points were added per race than make a seperate table points (user_id, race_id, points)
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 9 years ago.
Improve this question
Hi i am using php and mysql on my project and i wanted to know which is better (all aspect).
I am expecting a big amount of data in the database.
I want it to search faster.
Should i store the real value or a reference value.
1) Have php proccess it? Meaning I will store values in the database as integer/tinyint and then create a function to know the value to output. ie. if 1 then value is "north" elseif 2 then value is "east" and so on. values will not change.
let say i will have at least 20 of this function.
database design
id direction
1 1 (1=north)
output (use php to display the output)
north
2) Dump all data to database.
database design
id direction
1 north
I am guessing you are asking whether to store number of days as text or number. There is no reason whatsover to store the text. You can easily get the sentence from the number
#http://pear.php.net/package-info.php?package=Numbers_Words must be installed
include("Numbers/Words.php");
$row;//The row corresponding to your quert fetched from database
$nw = new Numbers_Words();
$sentence="I am ".$nw->toWords($row['howmanydays']);
It doesn't take a lot of time either.
Why not store the text? Good question
1. Text Occupies more space:
So your very large database will be using up a lot of unnecessary space that could easily be reduced by using numeric datatype
2. Numeric Operations
You can perform queries like where howmanydays> 10 which you can't if you store it as text
3. Internationalization
If you store it directly as text, Internationalization becomes more difficult. Now you can simply fetch the sentence from a language file and fill in the variable
Will the data change overtime, or are they fixed?
If the data can change, better store them in database so you don't have to keep changing your PHP code and just update the data in database as needed.
If the data is fixed, then just store it in PHP. Maybe you can just store it as array and access the record as needed.
$data = array (1 => 'i am one', 2 => 'i am two', 3 => 'etc');
echo "{$data[1]}"; // will output 'i am one'
Thanks for clarifying! If directions/ constants can never change, you can use an array of constants & and a couple of functions in PHP to encode/decode them from UI <-> internal & database values.
If there's not naturally an numeric value or semi-numeric sequential ordering, I would probably prefer to encode them as CHAR(1) or short VARCHAR constants. More readable in the DB as "N", "S", "E", "W" etc.
I use this scheme for record statuses & a soft-delete scheme -- active "A", on-hold "H", deleted "D". (Records are flagged as "D" deleted and hidden, rather than permanently being deleted from the database.)
OTOH for "workflow" type activity, in one place I use numerics to track WORKFLOW_STATE -- since the states can be considered as a roughly ascending sequence.
If directions/constants may change occasionally over time, but require application-code support -- they can also be treated as constants. For example: Tax Types. You can't implement a new "tax type" without code & knowing how to calculate it.
If OTOH the values may change or be added more frequently, and without application code-changes, then they should be configuration/ or a dimension table. For example: Tax Rates, Cities. You can implement a new or changed percentage tax-rate, for an already existing tax-type, without code change.