I have been given the task to combine 2 mysql fields into one and then make it so that the new field can be searched. The 2 fields I had to combine in my database where previous year registered and current years registered. The format both these fields are in are dd/mm/yyyy. I have combined these fields into a field called Years Registered whih is still in the same format dd/mm/yyyy but has the years registered seperated by a comma(,). I am wondering how I would go about performing a couple different kinds of querys on this column. The mysql queries I have to perform are: Show All() , Show All between dates: mm/yyyy and mm/yyyy , Before: mm/yyyy , After: mm/yyyy
Any help would be greatly appreciated.
Thanks for your time.
I don't like it but if you need you can use the next solution:
extract date using start_date = STR_TO_DATE(SUBSTRING(your_new_field, 1, 10))
and end_date=STR_TO_DATE(SUBSTRING(your_new_field, 12, 10))
Do not do this!
I do not know how it is exactly possible (some SQL Stringoperations and Datefunctions in a storedprocedurem i presume), but it will surely kill performance of your database.
use a relation for this.
This is:
way faster
more expandable (eg. for three dates..)
easier to code
much better understandable
more portable to other databases
If you have problems with existing platforms you have to support, use a code base where both alternatives are supported. This is still easier and better to maintain than to use a comma-separated list
Your database would be breaking 'First Normalized Form (1NF)' and would be highly ineffecient.
In order to search for a selected date, you would either have to query all rows in the table, or use LIKE which is also very sluggish.
Whoever is asking you to do this should read this article on database normalization.
What is wrong with using two DATE, or DATETIME fields and the formatting them outside of MySQL?
Related
I am currently working on a simple booking system and I need to select some ranges and save them to a mysql database.
The problem I am facing is deciding if it's better to save a range, or to save each day separately.
There will be around 500 properties, and each will have from 2 to 5 months booked.
So the client will insert his property and will chose some dates that will be unavailable. The same will happen when someone books a property.
I was thinking of having a separate table for unavailable dates only, so if a property is booked from 10 may to 20 may, instead of having one record (2016-06-10 => 2016-06-20) I will have 10 records, one for each booked day.
I think this is easier to work with when searching between dates, but I am not sure.
Will the performance be noticeable worse ?
Should I save the ranges or single days ?
Thank you
I would advise that all "events" go into one table and they all have a start and end datetime. Use of indexes on these fields is of course recommended.
The reasons are that when you are looking for bookings and available events - you are not selecting from two different tables (or joining them). And storing a full range is much better for the code as you can easily perform the checks within a SQL query and all php code to handle events works as standard for both. If you only store one event type differently to another you'll find loads of "if's" in your code and find it harder to write the SQL.
I run many booking systems at present and have made mistakes in this area before so I know this is good advice - and also a good question.
This is too much for a comment,So I will leave this as an answer
So the table's primary key would be the property_id and the Date of a particular month.
I don't recommend it.Because think of a scenario when u going to apply this logic to 5 or 10 years system,the performance will be worse.You will get approximately 30*12*1= 360 raws for 1 year.Implement a logic to calculate the duration of a booking and add it to table against the user.
I have a slight problem. I have a dataset, which contains values measured by a weather station, which I want to analyze further using MySQL database and PHP.
Basically, the first column of the db contains the date and the other columns temperature, humidity, pressure etc.
Now, the problem is, that for the calculation of the mean, st.dev., max, min etc. it is quite simple. However there are no build-in commands for other parameters which I need, such as kurtosis etc.
What I need is for example to calculate the skewness, mean, stdev etc. for the individual months, then days etc.
For the build-in functions it is easy, for example finding some of the parameters for the individual months would be:
SELECT AVG(Temp), STD(Temp), MAX(Temp)
FROM database
GROUP BY YEAR(Date), MONTH(Date)
Obviously I cannot use this for the more advanced parameters. I thought about ways of achieving this and I could only think of one solution. I manually wrote a function, which processes the values and calculates the things such as kurtosis using the particular formulae. But, what that means is that I would need to create arrays of data for each month, day, etc. depending on what I am currently calculating. So for example, i would first need to take the data and split it into arrays lets say Jan11, Feb11, Mar11...... and each array would contain the data for that month. Then I would apply the function on those arrays and create new variables with the result (lets say kurtosis_jan11, kurtosis_feb11 etc.)
Now to my question. I need help with the splitting of data. The problem is that I dont know in advance which month the data starts and which it ends, so I cannot set fixed variables for this. The program first has to check the first month and then create new array for each month, day etc. until it reaches the last record. And for each it would create the array.
That of course would be maybe one solution but if anyone has any other ideas about how to go around this problem I would very much appreciate your help.
You can do more complex queries to achieve this. Here are some examples http://users.drew.edu/skass/sql/ , including Skew
SELECT AVG(Temp), STD(Temp), MAX(Temp)
FROM database
GROUP BY YEAR(Date), MONTH(Date)
having date between date_from and date_to
I think you want a group of data in between a data range.
Hi i have a mysql database, in which i have two columns Year_from & Year_two.
what i am trying to do is find a way where i can show the dates that are missing as buttons, for example if year from is 2006 and year to is 2008, i of course want to show 2006, 2007 and 2008. is this possible, as there isn't the value of 2007 in the database.
I haven't worked on any code yet as i am not sure if this is possible, or how i would achieve it.
Any ideas would be appreciated.
Thanks
Use range($year_from, $year_to) to generate a list of all years. Compare that array with the one you got from the database using array_diff() and bold the missing ones.
This needs to be done in code.
Basically, you'll read a bunch of records from the database, iterate through an array of years you'd like to show and check (every iteration) if there is a matching record present in the result set.
I am working on script which requires giving the admin the ability to insert dates for when he wants a parking lot available, the admin inserts dates in a range.
I am having a hard time coming to a solution to what would be the best way to store the dates in MySQL.
Should i store the dates using two columns AVAILABLE_FROM_DATE and AVAILABLE_UNTIL_DATE?
PLID AVAILABLE_FROM DATE AVAILABLE_UNTIL_DATE
1 2012-04-01 2012-04-03
1 2012-04-05 2012-04-15
2 2012-04-21 2012-04-30
OR should i just use a single column AVAILABLE_DATE and store the ranges the admin selects in a new row for each date between the range?
[EDIT START]
What i mean above by using a single column is not to join or split the dates into a single column, i actually mean to store a date in a single row with a single column like below:
PLID AVAILABLE_DATE
1 2012-04-01
1 2012-04-02
1 2012-04-03
and so on for all the available dates i want to store.
[EDIT END]
Basically, the admin will want to insert a date range the parking lot is available and allow members to choose that slot if the user is looking for a slot within that range.
OR is there some better and simpler way to do this?
I am currently trying to use the first method using separate columns for the range, but having trouble getting the desired results when looking for parking lots within a range.
[EDIT START]
SELECT * FROM `parking_lot_dates`
WHERE (available_from_date BETWEEN '2012-04-22' AND '2012-04-30'
AND (available_until_date BETWEEN '2012-04-22' AND '2012-04-30'))
I use the following query on the above rows i have, and it returns empty.
I want it to return the last row having the PLID 2.
[EDIT END]
Thank you in advance.
Regarding your EDIT with the query, you have the logic inside out. You need to compare whether each date you are checking is inside the range BETWEEN available_from_date and available_until_date, like this:
SELECT * FROM `parking_lot_dates`
WHERE
(
'2012-04-22' BETWEEN available_from_date AND available_until_date
AND '2012-04-30' BETWEEN available_from_date AND available_until_date
)
Demo: http://www.sqlfiddle.com/#!2/911a3/2
Edit: Although if you'll want to allow partial-range matches, you'll need both types of logic, i.e., the parking lot is available 4-22 to 4-27, and you need it 4-23 to 4-28. You can use it for the dates 4-23 to 4-27, but not 4-28.
Why to complicate so much?
SELECT *
FROM `parking_lot_dates`
WHERE available_from_date <= '2012-04-22'
AND available_until_date >= '2012-04-30';
I personally have found it better to have 2 columns, a start and end time, for searching a specific date, or just looking at it seems easier to me
Using 1 column to store those dates is a bad design from a database point of view (not normalized). It's better to have 2 columns because the results can be retrieved easier and extracting the information from a single column would mean having to do some sort of split. It's just not elegant and it doesn't behave well when requirements change.
I'm working on a site where a user could select certain dates that apply to them, e.g Date 1,Date 2, Date 3, etc.
Each date will have certain questions belonging to it, so if the customer checked off 'Date 1' to indicate that this date applies to him, he'll then see a bunch of textboxes asking him about Date 1 and how it applies to them. Same goes for all other dates.
Date 1 and 2 and several questions, but the remaining dates have just 1 question.
These dates and their answers will later be used to create personalized reminders for the customer and sent out to him.
I'd also like a design which makes it simple (or as simple as possible) to add additional dates and fields.
My question is, what's the best way to store all the dates and their answers related to the user in the database? I was thinking that in the user table, I have boolean columns from Date 1 - Last date (obviously they're not actually named date 1, date 2 etc). If the column for Date 1 is set to 0, it means the customer didn't check it off, and if its 1 then it means he did and he answered the questions for it.
Regarding the actual storage of the dates, I'm considering these two options:
1) 1 table for each date, with columns for every question asked for that date and a user_id column. So in Date_1 table I'll have columns like Q1_name, Q2_name and the answers of the questions that the user gave.
But I want something more elegant because 1), it will make it a pain to fetch all the user's answers when calculating what info. applies to them when sending the personalized emails. 2) Some dates have only 1 question, so it'll be ugly to create a full-blown table for them.
2) A user_answer table, with the columns:
user_id,date_name,question_name,answer_val
2 seems the most elegant so far, but there should be a better solution. Any thoughts?
It sounds like you want something like the following (basic) table structure:
User - userId, userInfo
Date - dateId, dateInfo
Question - questionId, questionInfo
UserDate - userId, dateId - this stores all dates that apply for a given user and represents the many to many relationship between Users and Dates - a user can have many dates and a date can have many users
DateQuestion - dateId, questionId - this stores all questions that apply for a given date and represents the many to many relationship between Dates and Questions - a date can have many questions and, I assume, a question can be used against more than one date
UserResponse - userId, questionId, questionResponse - this stores all user responses to any questions asked. If you need to know which date the question applies to, assuming they can answer the same question more than once for multiple dates, add a dateId column.
Option 2 seems close to the good solution, but I'd replace date_name and question_name with date_id and question_id.
An optimal, and simplest solution that enables adding new questions and dates seems to be:
1. Dates table with the fields date_id, title, date.
2. Questions table with the fields question_id, date_id, title (and possibly type off the answer and description).
3. Answers table with question_id and answer.
You'll also need to decide whether or not you have questions that are common to several dates, and what to do in that case. (you may want two different answers, or a common answer). I'd recommend against the first solution, it'd make the question not dynamic - you'd have to change the sql and table structure for each change in the questions or dates.
I think you've pretty much got it, the only thing is you could possibly separate the question and date names into a separate table, giving you the following schema:
User: id, ... (name, date of birth, favourite food, etc)
DateName: id, name (called it DateName so no conflicts with the word Date, which could mean something else in SQL)
Question: id, date_id, text
UserAnswer: user_id, question_id, answer_val
It's not necessary to split them up, but there are three reasons to do it:
1. Lookups on integers (like question_id) as opposed to text (like question_name) is a lot faster because integers are smaller and fixed in size.
2. If you change the text to a question (like to correct a spelling mistake), you only need to change a single entry in Question, instead of on every single row.
3. Because you're storing each bit of text only once, you save a lot of space. Storing 1000 ints are smaller than storing 1000 strings. Well as long as the strings are longer than a few character that is.
Besides that I think that could work quite well.