Дублирование в БД. Как победить?

Question

[Alksar]

Напало дублирование, видимо из-за неверного проектирования.

Комментарии к схеме:
- к заказу (Order) привязываются услуги (Service) с помощью таблицы (Order_Service)
- каждая услуга заказа (Order_Service) выполнена сотрудником, связь: таблица (Employee_Order_Service)
- услуги представлены двух видов:
+ перевод (TranslationInfo), хранит имя текста, который переводят, языки с которого и на который переводят (LangFrom, LangTo)
+ заверение перевода (NotarialInfo), хранит, также имя текста, языки, кол-во копий заверения.

Но тут такой изъянище... Такая проблема, посмотрите, вид услуги "перевод" и "заверение" содержат много одинаковых полей, а именно: имя файла, язык 'с', язык 'на'. Поэтому при изменении, к примеру, имени текста - нужно будет менять его и в TranslationInfo и в NotarialInfo. Заверять можно только те тексты, которые переводились, так что лучше было бы разместить поле "CopyCount" в таблице "TranslationInfo", а таблицу "Notarial" не создавать вовсе! Но у заверения должен быть свой исполнитель, своя цена. У перевода тоже, соответственно, свой исполнитель и цена.
Как быть? Как исправить?

Answer 1

[Кирилл Пензин]

Создать два связанных поля: Employe_translation_id, Employe_notarial_id, к примеру. В остальном объединить. И поставить тригеры на то переведен ли документ, если да, то заверен ли?

UPD: Пусть у вас будет связь один-ко-многим от ServiceInfo к OrderService. Когда производиться заверение, вы просто добавляете для связи ещё одну запись из Order_Service и заполняете поле CopyCount. Таким образом, наличие значения в поле CopyCount и связь с двумя записями из Order_service(Два айдишника в поле Order_Service_id) будет являться условием для определения заверенности данного документа.

Comments

[Alksar]

Можно подробнее? Не понял, где создать эти поля?

[Кирилл Пензин]

Alksar: в общей таблице, которую вы хотели получить путём слияния TranslationServiceinfo и NotarialServiceInfo.

[Alksar]

Похоже, это действительно поможет! "Создать два связанных поля: Employe_translation_id, Employe_notarial_id" - это просто два поля в таблице в новой таблице ServiceInfo? Связаны логически? Т.е. если и там и там установлено значение, то мы знаем что текст заверен, так? Спасибо.

[Кирилл Пензин]

Alksar: Да, можно и так. Пожалуйста. Если не сложно, пометьте как ответ.

Answer 2

[Вадим Шандринов]

Тут простое наследование, кмк. Создайте базовую табличку ServiceInfo с общими для всех подтабличек полями. А табличку TranslationServiceInfo создайте с полем parent_id - FK на ServiceInfo, NotarialServiceInfo - аналогично. В них добавьте полей, специфичных для каждой. Когда будете выбирать из TranslationServiceInfo, то основные поля тяните связкой из ServiceInfo (к слову в ОРМ джанго это можно сделать через django-model-utils).

Comments

[Вадим Шандринов]

И как вариант - если у ServiceInfo есть наследник TranslationServiceInfo, то она переводилась, а если еще есть наследник NotarialServiceInfo - то и заверялась :)

[Alksar]

При таком подходе не понятно, как указать исполнителя перевода и отдельно исполнителя заверения

[Вадим Шандринов]

от таблички TranslationServiceInfo, к примеру, связь к исполнителю, точнее к строке заказа, который он обслуживал. Сама ServiceInfo по идее должна ссылаться на Service... или так: сервис - просто название услуги, а в Order_Service - детализация того как данный сервис в данном заказе выглядит (конкретика, что откуда и как переводилось) ? Тогда все поля, характеризующие это нужно вносить в Order_Service. То есть общая таблица ServiceInfo вся ложится в Order_Service, а TranslationServiceInfo характеризует как эта строка заказа была реализована и оттуда уже идет ссылка на того, кто сделал :)
И называться она должна OrderServerTranslation. (с заверением так же).

[Вадим Шандринов]

То есть - общие поля из TranslationServiceInfo и NotarialServiceInfo надо перенести в Order_Service; Employee_Order_Service - преобразовать в две Employee_Order_Service_Translation и Employee_Order_Service_Notarial

[Alksar]

Частично воспользовался Вашей идеей. Теперь появился вопрос, добавились еще две услуги, со своими параметрами, все бы ничего, смущает только то, что для каждого отдельного вида услуги - есть одна таблица исполнителей. Теперь, когда нужно делать выборку по исполнителям, приходится соединять все эти таблицы перед этим. Как вы считаете, насколько это неудачно, если можно так выразиться?

[Вадим Шандринов]

Хорошо бы посмотреть получившуюся схему. А так, если включить телепатию, - можно связку кто что делал привязать к строке конкретного заказа. И, если не трудно, отметьте мой ответ как решение.

Answer 3

[Максим Гречушников]

Полностью не вдавался вопрос.
Тригеры можт помогут? Бихэвиоры?

Comments

[Alksar]

Тригеры наверняка могут помочь, но это решение, когда изменить структуру уже нельзя, а я еще могу

[Максим Гречушников]

Alksar: с мсскл не работал, в php YiiFramework есть бехевиоры всякие, аналог тригеров, но со стороны бэкенда