Проектирование модели данных | Форум

7 Окт. 2015, 14:26

etalonim

Отклики: 5

7 Окт. 2015, 14:26

etalonim

Отклики: 5

Добрый день!

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

Надеюсь на Ваши советы.

Дано:

Есть некоторое множество транспортных средств (новые/подержанные легковые автомобили/легкий коммерческий транспорт/грузовые автомобили).
Транспортные средства могут быть описаны с разным уровнем детализации (Ford, Ford Focus, Ford Focus III, Ford Focus III хэтчбэк в комплектации Ambiente с двигателем X, Ford Focus III с VIN XXXXX).
Над транспортными средствами будет совершаться одинаковый набор действий, вне зависимости от уровня их детализации (рассчитать кредит, получить консультацию, рассчитать стоимость ТО, ...).

Задача:

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

Варианты решения:

Нормализованная структура:

class Brand(models.Model):
    # атрибуты: name, autoru_alias

class Mark(models.Model):
    brands = models.ForeignKey(Brand)
    # атрибуты: name, autoru_alias

class Generation(models.Model):
    marks = models.ForeignKey(Mark)
    # атрибуты: vin

class CompleteSet(models.Model):
    generations = models.ForeignKey(Generation)
    '''
    атрибуты: manufacturer, set_name, body_name, body_type, drive_name,
    drive_type, engine_name, engine_type, engine_volume, engine_power,
    gearbox_name, gearbox_type + M2M Options
    (денормализовал, чтоб не раздувать пример).
    '''

class Vehicle(models.Model):
    complete_sets = models.ForeignKey(CompleteSet)
    # атрибуты: vin, color

Этот вариант, кажется, не подходит, т.у. будет медленное чтении данных, например все VIN с brand_url=X, model_url=Y (а именно тут ожидается самая большая нагрузка). Кроме того, придется кучу всего писать под каждый уровень детализации транспортного средства.

Parent связь на себя + набор прокси классов, чтоб редактировать это хозяйство в админке:
```
class AbstractVehicle(models.Model):
    parents = models.ForeignKey('self')
    # атрибуты: все из примера выше + level

class Brand(AbstractVehicle):
    class Meta:
        proxy = True

class Mark(AbstractVehicle):
    class Meta:
        proxy = True

class Generation(AbstractVehicle):
    class Meta:
        proxy = True

class CompleteSet(AbstractVehicle):
    class Meta:
        proxy = True

class Vehicle(AbstractVehicle):
    class Meta:
        proxy = True
```
Все, кажется, здорово, скорость запросов чтения радует, фильтровать легко, в админке необходимую часть данных наследуем от родителя. Но не нормализовано ни разу... И если мы изменяем, например, brand_name в админке, начинаются пляски с бубном (понятно, что pre_save решает вопрос, но красивого способа найти детей не видно, да и, в целом, решение кажется не красивым).
Djang-mptt:

Все очень похоже на предыдущий пример, только данные не дублируем и свой атрибут level убираем (т.к. в mptt есть). Тут, толи я не до конца что-то понимаю, толи алгоритм предназначен слегка для других целей, но при выборке данных запросы усложняются. Кроме того, логика шаблонов усложняется (например, при выводе списка автомобилей node.brand_name уже не катит).

Вопрос:

Как лучше реализовать модель? Возможно, я не нашел каких-то альтернативных решений? Возможно я что-то не так понимаю?

Ответ | 0

7 Окт. 2015, 20:47 EvgIq Отклики: 329 Местонахождение: Samara	7 Окт. 2015, 20:47 EvgIq Отклики: 329 Местонахождение: Samara Характеристики ТС, нужные в работе, одинаковые для всех?
	Ответ \| 0

8 Окт. 2015, 12:45

etalonim

Отклики: 5

8 Окт. 2015, 12:45

etalonim

Отклики: 5

Характеристики ТС, нужные в работе, одинаковые для всех?

Да. То, что тут, будет одинаковым для всех, с небольшими различиями во вьюхе. Для грузовиков, и Б/У автомобилей модель может быть расширена.

Ответ | 0

8 Окт. 2015, 13:35

EvgIq

Отклики: 329
Местонахождение: Samara

8 Окт. 2015, 13:35

EvgIq

Отклики: 329
Местонахождение: Samara

Я бы сделал одну таблицу для всех ТС со всеми характеристиками (и VIN туда же). Специфичные характеристики заполнять только для тех ТС для кого они предусмотрены, для остальных - оставлять пустыми. Поле Б/у или новый - туда же. Таблица линейная, без иерархий.

Вторая таблица - иерархическая. Например: Легковой -> Ford -> Ford Focus -> Ford Focus III ->Ford Focus III хэтчбэк.

В первой таблице поле-ссылка на элемент из второй.

Вторую таблицу (иерархическую) можно на модели Djang-mptt. Но есть нюанс. Так как вся логика в коде Django, взаимодействие из других клиентов (моб приложение, CRM и проч) придется реализовывать самому.

Я бы использовал свое дерево. Вся логика работы с первичным ключем в нем в БД. Клиент же работает как с обычным связанным списком.

Плюсы: Все нужные операции за один запрос, быстрая выборка всех детей любого узла, для поиска списка id родителей и списка id всех детей - запрос не нужен, искомые списки вычисляются.

Минусы: Размерность дерева ограничена. Ее выбирают заранее.

Но пока приложение только для БД PostgreSQL. Принцип я описал здесь Думаю, за глаза бы хватило дерева с 7 уровнями и 564 возможными детьми у каждого узла (или 8х255 - точно хватит).

Обновлено 8 Окт. 2015, 13:48 EvgIq.

Ответ | 0

12 Окт. 2015, 12:45

etalonim

Отклики: 5

12 Окт. 2015, 12:45

etalonim

Отклики: 5

Спасибо, EvgIq!

Я читал обе Ваши статьи на хабре, когда искал решение. Большое за них спасибо! К сожалению, ограничение на размерность дерева может стать проблемой сразу на двух уровнях, что не позволяет использовать такое решение.

Так же предложенным Вами способом не решается проблема нормализации данных (общая таблица - по сути, наследует проблему из п.2 моего первого поста).

Зависимость от Djang-mptt меня, в принципе, не очень пугает, т.к. возможно back-end реализовать, как API, к которому сможет обращаться и front-end (на полном стеке БЭМ), и мобильные приложения, и все что угодно.

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

Ответ | 0

12 Окт. 2015, 16:26

EvgIq

Отклики: 329
Местонахождение: Samara

12 Окт. 2015, 16:26

EvgIq

Отклики: 329
Местонахождение: Samara

etalonim Понятно. Хотя, как Вы будете делать я не совсем таки понял :) Но удачи все равно!

Вопрос чисто для моего интереса... В предложенном примере,"Легковой -> Ford -> Ford Focus -> Ford Focus III ->Ford Focus III хэтчбэк" - всего 5 уровней вложенности. А можно попросить Вас показать пример, где уровней было бы больше, допустим 8-ми.

Ответ | 0

12 Окт. 2015, 18:00

etalonim

Отклики: 5

12 Окт. 2015, 18:00

etalonim

Отклики: 5

EvgIq, я, на самом деле, тоже не очень понимаю. Просто, пока, иду в сторону нормальных форм, а там будет видно.

Иерархия такая:

Бренд (Ford)
Модель (Focus)
Поколение (III)
Модификация (опишу ниже, тут с иерархия ломается)
VIN (опишу ниже)

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

Кузов и Комплектацию, кажется можно перенести в иерархию (хотя, может, и нельзя, забыл почему я их сюда определил). А, вот, Двигатель, Коробка и Привод могут быть одинаковыми для разных Моделей и, даже, разных Брендов, так что в иерархии им не место.

Вот, к этой Модификации и пристегиваются все остальные Опции (с которыми, на самом деле, все тоже не очень просто).

По хорошему, из Опций еще надо вытащить Цвет (он часто нужен).

Таких Модификаций может набраться достаточно много если автомобиль выпускается достаточно долго. И риск 1 - не поместиться тут в 564 детей (понятно, что меньше уровней - больше дочерних элементов, и риск не большой).

С VIN-номером - получается еще хуже, в не содержится VIS-номер (10-17 символы). Два из них - код года выпуска и код завода, остальные 6 - серийный номер, причем первые 2 его символа могут быть не только числами, но и буквами (почти полный англ. алфавит).

Получается, что 7-8-зачное число - потенциально возможное кол-во записей в VIN. Понятно, что они распределены по глобусу, и в рамках одного салона просесть маловероятно, но в рамках РФ - уже вполне реально (предполагается, что у нас в БД кроме автомобилей, которые сейчас в продаже, так же есть знания об автомобилях клиентов, которые просто порой приезжают на плановое ТО, ремонт, мойку, или, в крайнем случае, испить чашечку кофе).

Новый (в пути, на складе, забронирован) / подержанный (на складе, забронирован) / автомобиль клиента (приехал на ТО, итд) - это просто статус, который не является константой. Этот статус меняется с течением времени, а история его изменений нужна, так что это все вне этой модели.

Может, я не правильно понял Ваш совет, и с ним все нормально "взлетает"?

Ответ | 0

12 Окт. 2015, 20:53

EvgIq

Отклики: 329
Местонахождение: Samara

12 Окт. 2015, 20:53

EvgIq

Отклики: 329
Местонахождение: Samara

Не зная всех исходных данных и целей проекта, трудно что-то проектировать. Тем более я не в теме (про авто). что там и как :)

Постоянные, неизменные, поля - в основную таблицу. Изменяемые поля - внешние ключи на виды этих свойств.

В дерево - те постоянные(!) для ТС поля которые иерархичны, и по которым надо будет делать отбор. Из примера выше, допустим, можно очень просто выбрать все "Легковые" или все "Ford" или все "BMW"(думаю такая ветка у Вас будет :) ) (на самом деле довольно сложно придумать достаточно глубокую иерархию, хотя её легко можно сделать - если "иерархировать" неправильно)

По поводу того, что не влезут все модификации... Обойти это можно создав еще одного родителя уровнем выше. Например "Поколение III 1990-2000г" и "Поколение III 2000-2005г" и т.п.

Я так понимаю, что VIN - уникальный для каждого авто, и пусть в него запакованы еще какие-то данные, это обычное уникальное символьное поле для таблицы ТС.

Обновлено 12 Окт. 2015, 21:45 EvgIq.

Ответ | 0

12 Окт. 2015, 21:29

EvgIq

Отклики: 329
Местонахождение: Samara

12 Окт. 2015, 21:29

EvgIq

Отклики: 329
Местонахождение: Samara

Хотя, Ford, может быть и грузовой. Тогда легковой/грузовой/ещеКакойНибудь... не иерархическое свойство, а поле для таблицы ТС, с возможностью выбора из другой таблицы раз и навсегда (грузовая же не сможет стать легковой)

Теперь, возьмем, например "Цвет" - это поле для таблицы ТС. Оно может измениться, но искать ТС будут по тому цвету, которое оно имеет сейчас (то есть старые значения может и важны, но только при рассмотрении уже найденного авто). Изменение этого свойства (и подобных) - логировать в простую таблицу "Изменения" всего с двумя полями: id_ТС, и строка "Дата + Свойство +было + стало".

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

и т.д. и т.п... :) непросто вобщем всё это :)

Я бы, начал с проектирования структуры БД, с определения всех таблиц и связей. А потом бы уже думал о моделях и вьюхах :)

Обновлено 12 Окт. 2015, 22:12 EvgIq.

Ответ | 0