Я изучал проектный пример, в котором они обсуждают, как работать с дизайном базы данных системы, которая уже находится в разработке. Система предназначена для управления общественной парковкой. Основная дискуссия заключается в том, как отвечать следующим требованиям:Рекомендации по разработке баз данных с адресами
Система должна обеспечивать управление информацией каждой парковочной компании.
Данные хранятся в адресе автостоянки (подробности, провинция, округ, округ), название, корпоративная идентификация, количество мест.
Система должна обрабатывать отчеты о доходах, генерируемых каждой парковкой.
Эти отчеты должны разрешать фильтрацию по провинциям, так как компания имеет несколько парковки по провинции, некоторые из которых расположены в том же районе.
Некоторые люди упомянули, что стол ParkingLot должен иметь колоны для провинции, уезда и района и которые характерны для каждой парковки.
Другие говорят, что этого не должно быть. Мне было интересно, какой из них лучше всего подходит для разработки базы данных в этой конкретной точке. Что сводится к моим вопросам, в таких случаях (потому что должны быть исключения), где система довольно прямолинейна, действительно ли это имеет значение?
Что делать, если эти отчеты разрешают фильтрацию по провинциям? Поскольку компания может иметь несколько парковочных мест в одной провинции, некоторые из них расположены в том же районе.
Является ли район всегда в пределах графства и является округом всегда в пределах провинции? Или они могут накладываться странными способами? –
@WW. В провинции есть более одного округа, а округ имеет более одного района, всегда в таком порядке. Например, вы не можете иметь провинцию, страну, округ, округ. –
Остерегайтесь, город и графство Сан-Франциско в Калифорнии имеют один город в графстве. Неясно, является ли Калифорния провинцией в пределах вашего круга ведения; это звучит немного, как будто вы можете работать в Канаде. Вам нужно беспокоиться о структурах международных адресов? –