Link to home
Start Free TrialLog in
Avatar of Nkhanna
NkhannaFlag for United States of America

asked on

Data Organization

Hello,
I want to create an application that can take a certain data as input and hold it in the data base in a fashion that it is quick to search through it. Also, we want to be able to do 1000s of search simultaneously.

The Data:
The data in question is parking regulation information which varies from block to block in any given city. One block could have 3 hour parking from 8:00am to 8:00pm while the other block could have 2 hour parking and the third can have rush hour no parking from 4:00pm to 6:00pm but back to regular parking after 6:00pm till 8:00pm.
The elements are:
• Location
• Regular Parking Hours
• Rush Hour Time
• Truck Loading Time
• Loading Zones
• Valet Parking


Example:

GPS_Location = A:
Reg_Parking = <8:00am to 4:00pm> & <6:01pm to 10:00pm>
Rush_hour = 4:01Pm to 6:00pm
No_of_Meters = 3
Loading_Zone = Yes
Truck_Loading = <7:00am to 7:59am>

We want to organize this data so that one can use their mobile phone to send back a GPS location and receive information if they can park at that location.

I am not a programmer and so looking for some expert advice on how to go about thinking about this application such that we can input a CSV file with all the regulations information into the application and the application can organize the data.
Avatar of Kent Olsen
Kent Olsen
Flag of United States of America image

Hi Nkhanna,

If the data will accessed primarily by the location, you'll want to structure the table so that the location is the primary key or there is a clustered index on the location/time column(s).

Your data shows that you can have multiple times for an "event", in this case regular parking.  That's a level of complexity that you need to avoid.  Instead, define a row so that it defines the parking options over a time range.

A row in the table may cover 13:30 to 16:00 as "normal time".  Another row shows that "rush hour" starts at :16:00 and continues for 2 hours.  Another row would show "normal time" resuming at 18:00 and continuing until midnight.


There are certainly other ways to code the database, but I'd start with something like this.  Any "point in time" for a location is defined in exactly 1 row.


Good Luck,
Kent

--
--  Record parking options over time for this data:
--
-- GPS_Location = A:
-- Reg_Parking = <8:00am to 4:00pm> & <6:01pm to 10:00pm>
-- Rush_hour = 4:01Pm to 6:00pm
-- No_of_Meters = 3
-- Loading_Zone = Yes
-- Truck_Loading = <7:00am to 7:59am>

CREATE TABLE Parking
(
  id auto_increment ...,
  GPS_Location    location,
  StartTime       time,
  duration        integer, -- in seconds OR an EndTime
  NumberOfMeters  integer,
  RegularParking  integer,   -- true/false
  RushHour        integer,   -- true/false
  LoadingZone     integer,   -- true/false
  TruckLoading    integer    -- true/false
);

Open in new window

Avatar of Nkhanna

ASKER

So I guess it would be a linear table like the one I have attached. Can I reduce the size of the database by only putting in the regular hour such as
• Reg_Parking = 8:00am to 10:00pm
• Rush_Hour = 4:30pm to 6:30pm

and then let the logic figure out based on current time if the person can park here or not. Example:
If I send the GPS coordinate back to the server at 4:40pm then the backend can run the logic and figure out that this coordinate falls in the range of location that is now in rush hour time zone and hence will respond saying that "Rush Hour - Cannot park till 6:30pm"

Is there a better approach?
Parking-Table.xls
Hi Nkhanna,,

You can, but you take out some flexibility.  For example, most urban areas have morning and evening rush hours.  Some also have a noon rush hour.  If you want to track all 3, you'll need to have columns for all 3 in the row.  That's actually a very good way to store this data if it's consistent with your usage.

Based on your description, I think that you'll get the best performance with a smaller granularity to each row.  The table will have 1 or 2 indexes.  If you need to search by these other fields you'll actually increase the storage requirements of the indexes because you'll have more indexes on the same columns.  When searches (even by separate tasks) involve several indexes, more system memory is required to buffer the additional index blocks and more physical I/O is required.


Kent
ASKER CERTIFIED SOLUTION
Avatar of dragos_craciun
dragos_craciun
Flag of Romania image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial