История разработки модуля для хранения адресов. Часть 2

1st Февраль 2014 | Категории: Проектирование | Метки:

Продолжаем хождение по мукам. Начало истории

Часть 7. «Большое совещание или авторитет Википедии»

Во время очередного прихода Заказчик обратил внимание на таблицы с признаками: – «А что вы там будете хранить?». Это была феерия, братцы. То, что придумал сам Заказчик накануне, он просто забыл: – «Я не помню, чтобы мы это утвердили!».
Программист пытался привести примеры, но все усилия были тщетны:
Заказчик: – «Вот у нас таблица «Территория» – вот статья на Википедии о территории. «Населенный пункт» – вот статья в Википедии о населенных пунктах… А вот на схеме таблица «Признак населенного пункта» – где статья? Нет статьи… В самой Википедии нет статьи, значит такой таблицы быть не может. Что вы там собираетесь хранить? Вот у нас есть таблица «Описание» – там в тексте можно хранить всё, что угодно… В том числе и признаки населенных пунктов».

В итоге, от таблицы «Признаки Населенных Пунктов» было решено отказаться. Камнем преткновения стало понятие «тип». Вот есть у нас Населенный Пункт Москва, Тип – город. Есть у нас дом с номером 10, Тип – жилой. В признаках у него – 10 этажей и 3 подъезда.
Заказчик: «Таблица Признака дублирует поле тип. А почему бы нам не сделать тип жилой-трёхподъездный-десятиэтажный. Тогда таблицу с признаками можно совсем убрать». О_о.

Доводы Программиста, что так делать нельзя, что это не-по-реляционному и прочее – разбивались об «Докажи» Заказчика. Хотя в итоге две таблицы признаков остались неприкосновенными.
Также внезапно обнаружилось, что называть таблицу «Микрорайоны» неверно, ведь в городах бывают и другие административные единицы деления.

address_25

Часть 8. «Большое совещание… Оттепель…»

Следующее совещание началось с монолога Заказчика:
– «Я долго не спал после совещания. Я пытался найти решение. Нужно убрать полностью все таблицы с признаками (строений и помещений). Ведь все возможные значения признаков можно хранить в одном типе: «9этажный, 1подъездный, 36квартирный, жилой», «16этажный, 1подъездный, 36квартирный, жилой»…

Богатый букет эмоций Программиста сложно передать словами. Его голову стали посещать мысли: «что я тут делаю», «а может ну его всё нафиг»… И только спортивный интерес и желание доказать свою правоту помогали держаться.

На следующее совещание Программист подготовил тяжелую артиллерию: статьи по нормализации, теории реляционных баз данных, ER-диаграммы, примеры почему нельзя хранить все одной строкой. Совещание превратилось в тяжелый двухчасовой бой. Программист смог отстоять таблицы с признаками. В качестве компромисса пришлось переименовать их. Признаки строений -> Данные о строениях. Конкретизации подверглась и справочная таблица.
В оправдание Заказчика можно сказать, что его ввела в заблуждение терминология: «тип» и «признак». Чем тип отличается от признака? И если для Населенного Пункта тип – это город / деревня / ПГТ, то какой тип у Строения?
Программист имел ввиду, что строение может быть: жилой дом / офис / гараж. Но если в Википедии (будь она не ладна) набрать «тип дома», то мы попадём на статью «Типовые серии жилых домов». Из-за этого и получилась вся путаница. Хорошо, что в какой-то момент Программист и Заказчик нашли общий язык и утвердили новую версию структуры. Она мало чем отличается от прошлой: уточнены название и добавлены примеры.

address_26

Примеры таблиц с уточнением хранимых данных:
address_261

address_262

Subscribe without commenting


Пока комментариев нет.