Как создать базу данных парковки?

Question

Я пытаюсь создать базу данных, которая содержит данные об парковке на улице. Парковка имеет GPS-координаты, ограничение по времени, дням недели (некоторые дни разрешены, другие ограниченные), бесплатный или оплачиваемый статус. В конце концов, мне нужно сделать несколько запросов, которые могут определять парковку по критериям. Для первой перерисовки я пытаюсь сделать что-то вроде этого:

Pakring 
------- 
parkingId 
Lat 
Long 
Days (1234567) 
Time -- already here comes trouble 

Но это `ы не нормированные и быстро переполнения базы данных. Как правильно проектировать данные?

Update На данный момент у меня есть два подход Первые из них:

Я пытаюсь использовать Ограничение таблицу со многими ко многим ссылкам (Это пример в течение нескольких дней и месяцев).. Но запросы будут сложными, и я не буду сейчас связывать время с днем. Второй подход:

Использование одной ограниченной таблицы с полем типа, которое будет иметь приоритет. Но это решение также не нормировалось. Просто чтобы понять, какие у меня данные.

PakingId Coords String Description(NO PARKING11:30AM TO 1PM THURS) 

И я хочу показать пользователю, где он может найти уличную парковку по площади, времени и день. Спасибо всем за вашу помощь и время.

Answer 1

Попробуйте использовать две таблицы с объектом пересечения между ними.

Столовая парковка будет иметь parking_id, lat и длинные колонны. Ограничения таблиц будут иметь все типы ограничений, которые у вас есть в вашем сценарии, с такими же ограничениями: ограничениями, ограничениями_day, ограничениями и ограничениями_status и, возможно, ограничениями.

Затем вы можете связать две таблицы с ограничениями внешнего ключа в объекте пересечения.

Пример parking_id имеет ограничение_ид.

Таким образом, парковка может иметь более одного ограничения и ограничение может быть применено к нескольким стоянкам.

Answer 2

Как вы, кажется, слышали о нормализации и следуя комментарию от Damien, вы должны использовать разные таблицы для представления разных вещей.

Затем вы должны подумать о том, как связать эти таблицы вместе, и в процессе определите тип отношения между 2. Может быть индивидуально (это тот, где вы могли бы соблазняться поставить все в той же таблице, но простой внешний ключ в связанной таблице более чист), один-ко-многим (здесь проблема начнется, если вы поместите все в одну таблицу, так как теперь в связанной таблице будет несколько строк с тем же внешним ключом, и если все было в одной таблице, вы должны были бы поместить поля в эту таблицу) или многие из многих (где вам нужно будет добавить таблицу только для того, чтобы сделать ссылку между двумя другими таблицами , таким образом, с двумя полями внешнего ключа, указывающими на записи в обеих таблицах).

Например, в вашем случае, Parking таблица может содержать имя машины, координаты и т.д. Вторая таблица TimeTable может провести первые дни/время для каждой стоянки, с внешним ключом к parkingId (что делает его один-ко-многим rlationship, 1 парковка может иметь много открытий кадров).Поля этой таблицы могут быть, например, DayOfWeek (число, обозначающее день), время открытия, время закрытия. Это позволит вам определить несколько таймфреймов в один и тот же день или один (если он всегда открыт, например), указав в этом случае 7 записей в этой таблице для этой парковки (=> отношения «один ко многим»). Вы могли бы представить себе 3-й стол Price, где вы поместите данные о цене этой парковки (возможно, тоже один-ко-многим), с записями для почасовых ставок/длительное пребывание/... и т. Д. В зависимости от потребностей и разные «объекты», которые вам нужно будет представлять.

Обратите внимание, что это лишь приблизительные примеры. Дизайн базы данных иногда может быть очень сложным, и это вопрос, в котором я не специалист, но я думаю, что эти рекомендации помогут вам дальше и вернуться с другим вопросом, если вы застряли.

Успехов!

Answer 3

Это кажется трудной задачей. Очень коротко мысль.

Вас интересует только парковка на улице? Парковочные дома имеют несколько этажей, поэтому координаты GPS не будут работать, если вы не останетесь на улицах.

Какая точность координат? Было бы легче идентифицировать каждое парковочное место индивидуально по какому-либо другому стандарту. Как уникальные идентификаторы окрашенных парковочных площадей. (Но что происходит, если люди не припарковываются на квадраты? Или точность GPS-координат не получается/недостаточно точна из-за незаконной парковки? Вы также собираетесь вести учет парковочных билетов?)

Некоторые думали о таблицы или информация, которую вы должны принять во внимание:

1. время: часы, дни
2. цена: может быть другая цена на разные промежутки времени?
3. исключения: праздники, обслуживание (может быть, не так важно, вы можете просто сделать статус стоянки активный/неактивный)
4. парковка слот: идентификатор (GPS/случайный идентификатор), статус

Три или четыре таблицы выше могут быть связаны промежуточной таблицей, которая показывает свойства парковочного места для каждого возможного времени парковки (например, прототип для всех возможных комбинаций). Эта информация может быть связана с другой таблицей, в которой вы храните записи о фактических событиях парковки (так что вы можете, например, вести учет людей, которые имеют или не оплачивали свои счета, если вам нужно).

Есть много вещей, которые влияют на вашу реализацию, поэтому вам действительно нужно перечислить все правила парковки (и события?). Структура базы данных может быть выполнена (и переделана) позже после того, как у вас есть понимание свойств событий, необходимых для ведения записей. И это ключ ко всему: понимая, что вам нужно, чтобы сделать это, вы можете проектировать и создавать реализацию. Если реализация (приложение) не работает, измените реализацию. Если дизайн ошибочно перепроектирован. Если вы не разобрали весь процесс (что вам действительно нужно), все, что вы делаете, обязательно провалится. (Если вам невероятно повезло, но я не буду рассчитывать на удачу ...)