Postgresql MATCH PARTIAL работает вокруг?

-2

Я пытаюсь обойти отсутствие Postgresql 8.4 MATCH PARTIAL. У меня есть следующая схема:Postgresql MATCH PARTIAL работает вокруг?

[vehicles] 
lot_id | vin | source | year | make | model ... 
    primary key (lot_id, vin, source) 

[pictures] 
picture_id | lot_id | vin | url | sha1 ... 
    primary key (picture_id)

Теперь, что я хочу, это соединение FOREIGN KEY, что REFERENCES в vehicles таблицу, таким образом, что она требует lot_id и vin существовать в vehicles таблицы или ограничения целостности на pictures столе выходит из строя. Проблема в том, что эта функциональность доступна только в MATCH PARTIAL, которая не реализована. Есть ли другой способ легко получить этот эффект? До текущей итерации схемы мой стол для транспортных средств имел бы столбцы для каждого источника. automated_makeoverride_makevin_decode_make Это было беспорядок. Но, он появляется без MATCH PARTIAL Мне придется сделать большие изменения, чем я изначально планировал.

Я думаю, мне нужно будет сохранить два соединения indexes, чтобы достичь этого.

[index] 
lot_id, vin 
    primary key (lot_id vin)

Возможно переименование [vehicles] к [sources] в процессе; и затем заставляя [vehicles] и [pictures] - MATCH FULL против этих избыточных таблиц PRIMARY KEY.

источник

2010-08-10 Evan Carroll

У вас возникла эта проблема, потому что у вас плохая модель данных.

A vehicle должен быть однозначно идентифицирован vin (Идентификационный номер транспортного средства). Идентичность автомобиля не меняется в зависимости от того, в какой части он находится. И его фотографии вряд ли будут меняться в зависимости от того, в какой части он находится (если вам не нравится, например, «фотография этой Audi в Lot 4») ,

Таким образом, фотографии должны иметь внешний ключ на транспортном средстве (vin), а не автомобиль и много.

Теперь, транспортное средство может быть в много, и, возможно, для вашей модели, она должна быть много. Поэтому добавьте таблицу лотов и дайте машине FK.

Бит пули и изменить модель, а не тратить время на то, чтобы приспособить плохую модель.

источник

2010-08-10 20:21:37 tpdi

Автомобиль уникально идентифицирован вин, но строки в моем столе не имеют никакого отношения к «транспортным средствам в реальном мире», они имеют отношение к «транспортным средствам на сайтах», и есть корпоративные сайты и другие законные причины, по которым автомобили дублируются через lot_ids. Если у кого-то есть автомобиль на много и продает его на другой лот - вы думаете, что фотографии должны переноситься? Даже если этот автомобиль сидит перед вывесками вашего соревнования?В конечном счете, я могу доверять всему, что знаю о транспортном средстве, когда он появляется на другой лотерее. Он должен потерять всю свою историю. –

Да, плохая модель. У вас есть транспортные средства, партии и фотографии. Таким образом, у вас есть таблица транспортных средств, первичный ключ vin, таблица лотов с первичным ключом lot_id и множество таблиц, содержащих комбинации транспортных средств и лотов. Затем сделайте таблицу изображений ссылкой на эту таблицу. – MkV

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


[vehicles] 
lot_id | vin 
    primary key (lot_id, vin) 

[vehicle_data] 
lot_id | vin | source | year | make | model ... 
    primary key (lot_id, vin, source) 
    foreign key (lot_id, vin) references vehicles 

[pictures] 
picture_id | lot_id | vin | url | sha1 ... 
    primary key (picture_id) 
    foreign key (lot_id, vin) references vehicles

Даже если вы вручную переопределите части описания, это все тот же автомобиль.

источник

2010-08-10 21:37:42 Jeltz

Это плохая модель. Вы либо хотите соответствовать, либо нет. Вся частичная идея существует конкретно для борьбы с плохими моделями. Если у вас действительно нет другого выбора, напишите триггер.

источник

2010-08-11 16:59:27

ответ

Смежные вопросы