I like to prevent the last-service double- or cross-bookings.
at the moment many users can check the availability (at the same time) for the same service, getting the availability and all can book the same service/ on the same date. which is a big problem and caused over-bookings.
any idea how to prevent this in Laravel?
Thanks
You need a way to know how many users have booked for a particular service for a particular day
You also need to set a max number of bookings for each service for a day
Just before you save which user has booked a particular service, you can check if the service is fully booked, by checking the number of users that have already booked the service for that day if it is less than the max number of bookings and act accordingly
if you need more clarification or need help designing the database, ask
Related
I am creating a membership management database. One of the aspects I want to keep track of is the duration of a membership, and I want to keep track of any breaks in membership also.
Example:
A person joins , they renew each year on time for 3 years, but then there is a lapse in renewal for 2 months on the 4th year, and then they renew. I would like to be able to see the membership period of 3 years, the 2 month lapse, and then the new renewal.
Currently (see image), I originally was planning on just updating the membership_expire field to be a year from the date of the latest renewal but then realized I would be losing the previous membership renewal history by updating that field.... So how do I work around that?
I have a feeling the solution may be to create a seperate table to keep track of each renewal but I am not sure that is the best way to do it.
The database should reflect the reality.
If a "membership" can have multiple renewals, with different periods,
then your data structure should support it.
meaning- you need to create another table with FK to membership,
and each row would represent a period of time (start and expires)
Context:
I am working on a tele-health application that allows clients to choose an appointment type and then choose an available time slot to take that appointment. The client can only choose the appointment type and have no access to data regarding the available doctors
Procedure:
Client chooses appointment type
A Calendar is populated with available appointments for the next 30 days (sample calandar)
Once the client selects an appointment, one of the available doctors that can provide the service are assigned to them
Variables:
Each doctor has availability slots within weekdays (might have more than one on the same day)
One doctor may give more than appointment type
each service has a duration (some appointment types are set to 30 minutes and some maybe up to 60 minutes)
Problem:
Right now I am having trouble with:
listing the available time as shown in the sample calendar above in an efficient manner. Efficiency is key as this data will be needed to be retrieved a lot. I tried creating a view that has all the possible appointments, but that solution is extremely redundant.
Accounting for appointments of different duration
Current Database Design
Ideally I would like to return a list of JSON objects that contain the available start times per day (for the next 30 days) and a list of doctor id's that can handle this appointment.
Assuming that the time slots are all the same length, then you can create a calendar of all the time slots that are available.
I would suggest that each "slot" (appointment) have the information in your appointment table -- but with the caveat that "empty" appointments would also be included. Or, have the slots as a separate table with an appointment_id when the slot is taken.
Presumably, there is some limit on when future appointments can be made -- say 3 months in the future or one year in the future. Have a weekly job that adds another week in the future to the table.
Then you can summarize and readily see both available slots and unavailable appointments.
I am working with money expiration tracking problem at the moment (originally it is not money, but I have used it as a more convenient example).
An user can earn money from a platform for some mysterious reason and spent them for buying stuff (products, gifts etc.).
I am looking an algorithm (SQL query best case) to find a current balance of an user balance.
The events of spending and earning money are stored different database (MySQL) tables (let's say user_earned and user_spent). So in normal case, I would simply count user totals from user_earned and subtract spent money (total of user_spent).
BUT! There is a condition, that earned user money expires in 2 years if they are not used.
That means, if user have not used his money or used just a part of it, they will expire. If an user uses his money, they are used from the oldest not expired money record, so the balance (bonus) could be calculated in user's favor.
These are 5 scenarios with events in time, to have a better understanding on the case:
Both tables (user_earned and user_spent) have timestamps for date tracking.
I did something similar in one of my projects.
Looks like you need an additional table spends_covering with columns
spend_id, earhed_id, sum
So for each spends record you need to insert one or many rows into the spends_covering to mark 'used' money.
Then balance would be just sum of not used where date is less than 2 years.
select sum(sub.earned_sum-sub.spent_sum) as balance
from
(select e.sum as earned_sum, sum(sc.sum) as spent_sum
from earned e
left join spends_covering sc on e.earhed_id=sc.earhed_id
where e.date BETWEEN ...
group by e.earhed_id
having earned_sum > spent_sum) sub
It may be worth it to have two tables -- one (or more) with all the historical details, one with just the current balances for each 'user'. Be sure to use transactions to keep the two in sync.
I want to design a traffic exchange script that counts incoming traffic and tries to return a n:m (1in:2out for example) ratio of traffic. In the database, I want to have the sites info (SITE), then track traffic by site and ip (DAILY-HITS), then I want to have the trade counted per hour or day - not sure yet (SITE-TOTAL-HITS). I would love any suggestions I can get for designing a well designed database for handling traffic trades.
Right now I'm worried about tracking the incoming hits, later worry about returning. So basically my real question is, how can I design a database that can be efficiently used for returning the perfect amount of traffic for say the last 24 hours. The problem I'm having is, when it comes to programming, I want to have the best designed database for getting information on the last 24 hours and making sure I stay within the n:m ration. Heres what I've designed so far for the database:
SITE (just basic info):
id,
url,
title,
description.
DAILY-HITS:
id,
site_id,
ip,
date (include time - will be broken down per hour),
amount (count how many hits from this ip for this hour).
SITE-TOTAL-HITS (probably be updated every hour via script - useful later for counting last 24 hours):
id,
site_id,
year,
month,
day,
hour.
Any tips, suggestions or point me in the right direction would be greatly appreciated. Thanks in advance.
Here is my take on it for what it's worth:
Site:
Same as what you have
Traffic:
id,
site_id,
ip,
request_DateTimeStamp <- this is a date and time for the url request
no count here, just logging here is why:
assume you do have a count column
- url is requested
- lock up a record in the database with the same date and hour and ip
- Found, update the account
- Not Found, Create a new record and set the count to 1
this is a long process for a table that will presumably be updated a lot, within an hour span multiple request from the same ip will try to update the same record and they will have to wait on each other.
take out that count column and your process is simply to log the incoming traffic by always creating new records.
as far as data analysis is concerned, you can do it in couple of ways:
you can try building cubes: http://datacharmer.blogspot.com/2010/01/multi-dimensional-cubes-in-mysql.html
or you could create information aggregation tables like site_total_hits and just update them using nightly jobs or is often as you wanna run them depending on how accurate they have to be.
these are my 2 cents :D
You can use HitLeap to do that.
What is HitLeap? HitLeap is a Traffic Exchange, also known as an autohits service We help you increase your website hits, rankings (alexa, google) and more. Our affiliate program gives cash and traffic commissions of up to 50%. How does it work? After signing up, you will submit all the websites you want to send traffic to. Then you will earn free traffic by viewing other people's websites. Alternatively, you could buy a traffic package from us.
Go tho this link to sign up
Assume a simple database for hotel reservations with three tables.
Table 1: Reservations
This table contains a check-in and check-out date as well as a reference to one or more rooms and a coupon if applicable.
Table 2: Rooms
This table holds the data of all the hotel rooms with prices per night and number of beds.
Table 3: Coupons
This table holds the data of all the coupons.
Option #1:
If you want to get an overview of the reservations for a particular month with the total cost of each reservation, you'd have to fetch the reservations, the rooms for each reservation, and the coupon (if one is present).
With this data, you can then calculate the total amount for the reservation.
Option #2:
However, there is also another option, which is to store the total cost and discount in the reservation table so that it is much easier to fetch these calculations. The downside is that your data becomes much more dependent and much less flexible to work with. What I mean is that you have to manually update the total cost and discount of the reservation table every time you change a room or a coupon that is linked to a reservation.
What is generally recommended in terms of performance (option #2) version data independence (option #1).
UPDATE:
It is a MySQL database with over 500 000 rows (reservations) at this point, but is growing rapidly. I want to optimize database performance at an early stage to make sure that the UX remains fast and responsive.
Let me start to answer this with a story. (Somewhat simplified.)
2011-01-01 I reserve a room for two nights, 2011-03-01 and 2011-03-02. You don't tell me which room I'll get. (Because you don't know yet which room I'll get.) You tell me it will cost $40 per night. I have no coupons. You enter my reservation into your computer, even though you're already fully reserved for both those nights. In fact, you already have one person on the waiting list for both those nights. (Overbooking is a normal thing, not an abnormal thing.)
2011-01-15 You raise the rates for every room by $5.
2011-02-01 I call again to make sure you still have my reservation. You confirm that I have a reservation for two nights, 2011-03-01 and 2011-03-02, at $40. (Not $45, your current rate. That wasn't our deal. Our deal was $40 a night.)
2011-02-12 One person calls and cancels their reservation for 2011-03-01 and 2011-03-02. You still don't yet have a room you know for certain that I'll be able to check in to. The other person from the waiting list now has a room; I'm still on the waiting list.
2011-02-15 One person calls and cancels their reservation for 2011-03-01 and 2011-03-02. Now I have a room.
2011-03-01 I check in with a coupon.
You can store the "current" or "default" price with each room, or with each class of
rooms, but you need to store the price we agreed to with my
reservation.
Reservations don't reserve rooms; they reserve potential rooms. You
don't know who will leave early, who will leave late, who will
cancel, and so on. (Based on my experience, once in a while a room will
be sealed with crime scene tape. You don't know how long that will last, either.)
You can have more reservations than room-nights.
Coupons can presumably appear at any time before check out.
If you want to get an overview of the reservations for a particular
month with the total cost of each reservation, you'd have to fetch the
reservations, the rooms for each reservation, and the coupon (if one
is present).
I don't think so. The price you agreed to should be in the reservation itself. Specific rooms can't resonably be assigned until the last minute. If there's one coupon per reservation, that might need to be stored with the reservation, too.
The only reporting problem is in making sure your reports clearly report how much expected revenue should be ignored due to overbooking.
The response of your answer depends of the size of your database. For small database option #1 is better, but for huge database option #2 is better. So if you could say how many rows you got in table, and the database used (oracle, sqlserver etc.) you will have a more precise answer.
You can add a table holds the data of the rooms`s historical prices and reason for change.
Table 2 only records the latest price.