| |
 28 Кб. |
|
| | Проектируем систему бронирования отелей, а точнее структуру базы пока.
Прилагаю скрин структуры к которой пока что пришли и сам файл (по скрину не все связи видны - некоторые с удалением подчиненных, некоторые без)
И так что требуется - сами отели с описаниями, клиенты, продажи, поставщики, платежи, агенты, факт продажи есть основная связуящая . В продаже может быть
один/несколько разных клиентов (берутся из отдельной таблицы),
у каждой продажи может быть один/несколько поставщиков,
в каждой продаже может быть несколько услуг (не всегда соответствует количеству поставщиков)
У каждой продажи есть свой номер (чтото типа номера фактуры, нечто типа AB8034)
Агенты (справочник таблица agents) используются как клиенты, т.е. когда продаем за комиссию, но она просто вынесена отдельно т.к. специфика работы с агентами немного иная и информация отличается от информации клиентов.
Отели привязаны к городам, города к странам, цены разнесли по годам, так будет проще работать?, просто заводить новую таблицу каждый год. Каждый отель имеет тип комнат (обычно 3-5, но у разных отелей они могут быть и 10ти типов и называться по разному), у каждого типа комнаты на данную дату есть своя цена.
Формирование продажи идет по принципу "нет услуги - нет продажи", "нет заданной комнаты в заданную дату в данном отеле" - нет продажи", нет "поставщика - нет услуги".
Задачи - избежать скопление мусора в базе изза неверных связей и минимизировать повторяющиеся данные, сделать систему бронирования максимально гибкой.
Какие мнения есть на этот счет и правильно ли сделана структура? Спасибо.
Здесь скрин структуры - http://i529.photobucket.com/albums/dd331/iamxxii/ver2.gif | |
| |
| |
|
|
| |
|
|
| | в смысле "хорошо" или в смысле "плохо"?  | |
| |
| |
| |
|
|
| | в смысле - "фиг его знает "  | |
| |
| |
| |
|
|
| | Круто!!!!!!!
Красивая схема связей таблиц.
Работа проделана большая - видимо.
Молодцы!!! | |
| |
| |
| |
|
|
| | Блин, хватит меня пугать. Что в самом деле так все плохо связано?
Покритикуйте плиз! | |
| |
| |
| |
|
|
| | Ну, если Вы настаиваете. ;-)
Работать Вы собрались только четырнадцать месяцев
Таблица bookings_data будет содержать повторяющиеся данные. Также она расчитана в основном на тех, кто летает самолётами. Если я ошибаюсь, поправьте.
Чем вызвано связывание таблицы bookings_data с другими либо по ключевому полю ID, либо по полю booking_n?
Раз у Вас уже есть таблица городов и стран, можно было бы связать их с данными о клиентах, поставщиках.
Т.к. каждый отель имеет свои типы номеров, может было бы логичнее связать таблицы отелей и типов номеров.
И последнее, любой оптимизатор таблиц Вам скажет, что таблица agents не связана с другими таблицами :-)
Всё вышесказанное - лишь моё личное мнение, не являющееся истиной в последней инстанции. | |
| |
| |
| |
|
|
| | вчитываться и разбираться совершенно нет времени, да и лень честно говоря.
что бросилось в глаза:
Отдельные таблицы под прайсы разных лет... в 2010 будет еще одно поле и еще одна таблица?
В общем это недопустимо. Почему такое решение?
таблица clients_contact_attributes - висит в "воздухе" она что и зачем?
таблица payments_clients - не содержит ссылки на клиентов... хотя по идее должна
непонятно назначение таблицы link_clients_sales как и link_suppliers_sales
Лучше было бы написать что в какой таблице предполагается хранить, и какая для каких целей всякую лабуду типа фио клиента и прочего на этом этапе можно опустить.
т.е. на схеме в таблице нужны только поля участвующие в связях
а в описании что в какой таблице предполагается хранить (и почему вы решили именно так)
и желательно все это по русски в том числе и название таблиц и полей (т.е. это даже не название полей а их описание)
Вообще как сами понимаете создание структуры БД задача сложная и требует досконального понимания предметной области и особенностей документооборота конкретной фирмы. | |
| |
| |
