[Проектирование БД] Автобаза - критика и советы

@Artmal · Регистрация: 14.11.2015

Студворк — интернет-сервис помощи студентам

Задание: разработать веб-приложение.

Предметная область:

Кликните здесь для просмотра всего текста

Диспетчер создает Рейсы, которые представлены в системе в виде списка, для которого необходимо реализовать возможность сортировки по:

номеру рейса;
дате создания рейса;
статусу (открыт, в прогрессе, закрыт, отменен).
Водитель делает Заявку на рейс, в которой указывает характеристики автомобиля, необходимых для рейса. Диспетчер просматривает Заявку и назначает на рейс Автомобиль, который соответствует требованиям и находится в исправном состоянии.

Водитель делает отметку о выполнении рейса и состоянии автомобиля.

Администратор владеет такими же правами, как и диспетчер, кроме того может:

регистрировать водителей и диспетчеров в системе;
добавлять/удалять автомобили, редактировать информацию об автомобилях.

Пока набросал такой дизайн:

[Проектирование БД] Автобаза - критика и советы

Нужен свежий взгляд: где ошибаюсь, что не учел(а по ПО может пригодится в дальнейшем).

Особенности веб-приложения:
1. Регистрация доступна только для водителей - администраторы добавляются в БД вручную, диспетчеры добавляются администратором.
2. Справочники не используются в большинстве случаев для упрощения back-end кода - значения от мусора и пользовательских значений будут "защищать" селект боксы.

@pincet · 01.09.2017, 15:20

УГ в части trips и cars

@Artmal · 01.09.2017, 17:45 **[ТС]**

В trips оставил только один id. Дальше прочитать ваши мысли не смог.

Добавлено через 42 минуты
Еще увидел, что в таблице cars неключевые столбцы manufacturer и model зависят друг от друга. Скорее всего объеденю в один столбцев manacturer&model, т.к мне вряд ли придется часто делать сортировку машин по производителю/модели.

Добавлено через 10 минут
Все же интересно, как это нормализовать. Если я вынесу отдельные таблицы manufacturers, models и manufacturer_models, то возникают следующие вопросы:
1. Разрешить ли пользователю вносить новые типы производителей/моделей? Чем это может грозить?
2. Если не разрешить, то нужно найти список всех производителей(моделей точно невозможно все внести) и разрешать только из этого списка брать значения, но это неудобно с точки зрения ux + что если появится новая фирма.

@Пытливый · 02.09.2017, 14:14

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

@Artmal · 02.09.2017, 14:22 **[ТС]**

Передалал немного, использовав generalization pattern для разных типов пользователей.

Пытливый, тип поездки указывается в trips#trip_type. Значения будут ограничены селект боксом(напр. перевозка строй-материалов, кортеж, эвакуатор, переезд). Далее, у каждой поездки будет своя страница, где будет раздел "Машины". Там диспетчер будет заполнять какой-тип машины нужен(напр. для перевозки строй материалов ему будут нужны грузовики). Если у водителя есть машина типа грузовик, то он может подать заявку.

Я сам еще думаю над этой частью, возможно вы предложите дизайн более подходящий для этой системы.

@pincet · 03.09.2017, 13:13

Чувак, когда поймёшь умом, что не ведение справочников - зло, тогда и принимайся проектировать БД. А пока да, развлекайся и что-то-там ограничивай и защищай "селект боксами
"

Новые блоги и статьи Все статьи Все блоги /
Перемещение выделенных строк ТЧ из одного документа в другой Maks 30.03.2026 Реализация из решения ниже выполнена на примере нетипового документа "ВыдачаОборудованияНаСпецтехнику" с единственной табличной частью "ОборудованиеИКомплектующие" разработанного в конфигурации КА2. . . .	Functional First Web Framework Suave DevAlt 30.03.2026 Sauve. IO Апнулись до NET10. Из зависимостей один пакет, работает одинаково хорошо как в режиме проекта так и в интерактивном режиме. из сложностей - чисто функциональный подход. Решил. . .	Автоматическое создание документа при проведении другого документа Maks 29.03.2026 Реализация из решения ниже выполнена на нетиповых документах, разработанных в конфигурации КА2. Есть нетиповой документ "ЗаявкаНаРемонтСпецтехники" и нетиповой документ "ПланированиеСпецтехники". В. . .	Настройка движения справочника по регистру сведений Maks 29.03.2026 Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии. . . .
Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .	Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .	Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .

@Artmal 88 / 86 / 55 Регистрация: 14.11.2015 Сообщений: 1,099

	[Проектирование БД] Автобаза - критика и советы 01.09.2017, 14:16. Показов 1591. Ответов 5 Метки нет (Все метки) Задание: разработать веб-приложение. Предметная область: Кликните здесь для просмотра всего текста Диспетчер создает Рейсы, которые представлены в системе в виде списка, для которого необходимо реализовать возможность сортировки по: номеру рейса; дате создания рейса; статусу (открыт, в прогрессе, закрыт, отменен). Водитель делает Заявку на рейс, в которой указывает характеристики автомобиля, необходимых для рейса. Диспетчер просматривает Заявку и назначает на рейс Автомобиль, который соответствует требованиям и находится в исправном состоянии. Водитель делает отметку о выполнении рейса и состоянии автомобиля. Администратор владеет такими же правами, как и диспетчер, кроме того может: регистрировать водителей и диспетчеров в системе; добавлять/удалять автомобили, редактировать информацию об автомобилях. Пока набросал такой дизайн: Нужен свежий взгляд: где ошибаюсь, что не учел(а по ПО может пригодится в дальнейшем). Особенности веб-приложения: 1. Регистрация доступна только для водителей - администраторы добавляются в БД вручную, диспетчеры добавляются администратором. 2. Справочники не используются в большинстве случаев для упрощения back-end кода - значения от мусора и пользовательских значений будут "защищать" селект боксы. 0

@pincet 1655 / 1154 / 173 Регистрация: 23.07.2010 Сообщений: 6,910
	01.09.2017, 15:20
	УГ в части trips и cars 0

@Artmal 88 / 86 / 55 Регистрация: 14.11.2015 Сообщений: 1,099
	01.09.2017, 17:45 [ТС]
	В trips оставил только один id. Дальше прочитать ваши мысли не смог. Добавлено через 42 минуты Еще увидел, что в таблице cars неключевые столбцы manufacturer и model зависят друг от друга. Скорее всего объеденю в один столбцев manacturer&model, т.к мне вряд ли придется часто делать сортировку машин по производителю/модели. Добавлено через 10 минут Все же интересно, как это нормализовать. Если я вынесу отдельные таблицы manufacturers, models и manufacturer_models, то возникают следующие вопросы: 1. Разрешить ли пользователю вносить новые типы производителей/моделей? Чем это может грозить? 2. Если не разрешить, то нужно найти список всех производителей(моделей точно невозможно все внести) и разрешать только из этого списка брать значения, но это неудобно с точки зрения ux + что если появится новая фирма. 0

@Пытливый 3763 / 2267 / 705 Регистрация: 29.05.2013 Сообщений: 9,622
	02.09.2017, 14:14
	Несколько неясно целевое использование автомобиля и соответственно критерии отбора автомобиля. Для разного рода перевозок важны разные характеристики автомобиля, то что подходит для пассажирских перевозок, совсем не нужно для грузовых и наоборот. 0

@Artmal 88 / 86 / 55 Регистрация: 14.11.2015 Сообщений: 1,099
	02.09.2017, 14:22 [ТС]
	Передалал немного, использовав generalization pattern для разных типов пользователей. Пытливый, тип поездки указывается в trips#trip_type. Значения будут ограничены селект боксом(напр. перевозка строй-материалов, кортеж, эвакуатор, переезд). Далее, у каждой поездки будет своя страница, где будет раздел "Машины". Там диспетчер будет заполнять какой-тип машины нужен(напр. для перевозки строй материалов ему будут нужны грузовики). Если у водителя есть машина типа грузовик, то он может подать заявку. Я сам еще думаю над этой частью, возможно вы предложите дизайн более подходящий для этой системы. 0

@pincet 1655 / 1154 / 173 Регистрация: 23.07.2010 Сообщений: 6,910
	03.09.2017, 13:13
	Чувак, когда поймёшь умом, что не ведение справочников - зло, тогда и принимайся проектировать БД. А пока да, развлекайся и что-то-там ограничивай и защищай "селект боксами " 0