Рефакторинг базы данных для поддержки многих: многих: многих. На втором и третьем уровнях нам необходимо сохранить отображение конечных пользователей или сопоставление данных из разных источников, например,
Order 17
FirstpartyOrderID => aha
LineItem_for_BigShinyThingy => AA-1 # maps to 77-a
LineItem_for_BigShinyThingy => AA-2 # maps to 77-b, 77-c
LineItem_for_LittleWidget => AA-x # maps to 77-zulu, 77-alpha, 99-foxtrot
LineItem_for_LittleWidget => AA-y # maps to 77-zulu, 99-foxtrot
LineItem_for_LittleWidget => AA-z # maps to 77-alpha
ThirdpartyOrderID => foo
LineItem_for_BigShinyThingy => 77-a
LineItem_for_BigShinyThingy => 77-b
LineItem_for_BigShinyThingy => 77-c
LineItem_for_LittleWidget => 77-zulu
LineItem_for_LittleWidget => 77-alpha
ThirdpartyOrderID => bar
LineItem_for_LittleWidget => 99-foxtrot
Каждый LineItem имеет ежедневные точки данных, сообщаемые из его собственного источника (Firstparty | Thirdparty).
В нашем пользовательском интерфейсе и приложении мы предоставляем инструменты для их выравнивания, а затем мы хотели бы сохранить их в самой чистой из возможных схем запросов, что позволит нам анализировать сообщаемые ежедневные точки данных и выполнять другие ежедневные вычисления (которые мы сохраните в базе данных также, к счастью, это должно быть пирогом, как только мы это сделаем).
Нам нужно отобразить связанные [firstparty | thirdparty] line_items, которые имеют свои собственные точки данных. Мы будем использовать ассоциацию для извлечения каждой коллекции точек данных line_items для сводных расчетов и расчетов расхождений.
Я рассматриваю два варианта: std has_many, через x2 - или-- возможно (страшно) ubermasterjoin table
OptionA:
order<<-->>
order_join_table[id,order_id,firstparty_order_id,thirdparty_order_id]
<<-->>line_item
order_join_table[firstparty_order_id]-->raw_order[id]
order_join_table[thirdparty_order_id]-->raw_order[id]
raw_order-->raw_line_items[raw_order_id]
line_item<<-->>
line_item_join[id,LI_join_id,firstparty_LI,thirdparty_LI
<<-->>raw_line_items
line_item_join[firstparty_LI]-->raw_line_item[id]
line_item_join[thirdparty_LI]-->raw_line_item[id]
raw_line_item<<-->>datapoints
=> мы полагаемся на объединение для хранения всех отображений первых | третьих заказов и line_items
=> ключи к raw_ * включают поиск этих деталей заказа и line_item
=> опасения по поводу циклических ссылок и / или отсутствия правильной логики отображения, например,
заказ -> line_item -> raw_line_items
против
заказ -> raw_order -> raw_line_items
OptionB:
order<<-->>
join_master[id,order_id,FP_order_id,TP_order_id,FP_line_item_id,TP_line_item_id]
join_master[FP_order_id & TP_order_id]-->raw_order[id]
join_master[FP_line_item_id & TP_line_item_id]-->raw_line_item[id]
=> каждая комбинация FP_line_item + TP_line_item записывает запись в таблицу join_master
=> «теоретически» запросы легко / быстро / гибко / сексуально
Наконец-то мои вопросы:
а) любые уроки из мучительного непосредственного опыта о том, как лучше всего реализовать / настроить / оптимизировать отношения «многие ко многим ко многим»
б) в рельсах?
в) какие-нибудь болезненные ошибки (циклические ссылки, медленные запросы, спагетти-монстры), на которые стоит обратить внимание?
г) какая-нибудь радость и добро в Rails3, которые делают это волшебно легким и радостным?
д) кто-нибудь написал "как сделать схему" многие ко многим ко многим "в Rails и сделать ее быстрой и сексуальной?" учебник, который я как-то не нашел? Если нет, я продолжу наши уроки в надежде, что это поможет.
Заранее спасибо -
--Jeff