Здравствуйте, wildwind, Вы писали:

ЗХ>>И тут внезапно встает следующая задача: выбрать все obj_id, для которых верны следующие условия:
W>Прям-таки внезапно? О чем думали при проектировании?

У Тома Кайта эта тема давно раскрыта: здесь.

В общем, господа программисты "минус" разработчики, НИКОГДА, НИКОГДА так больше не делайте

Здравствуйте, PNCHL, Вы писали:

PNC>У Тома Кайта эта тема давно раскрыта: здесь.
PNC>В общем, господа программисты "минус" разработчики, НИКОГДА, НИКОГДА так больше не делайте

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

Здравствуйте, PNCHL, Вы писали:

ЗХ>>>И тут внезапно встает следующая задача: выбрать все obj_id, для которых верны следующие условия:
W>>Прям-таки внезапно? О чем думали при проектировании?

PNC>У Тома Кайта эта тема давно раскрыта: здесь.

PNC>В общем, господа программисты "минус" разработчики, НИКОГДА, НИКОГДА так больше не делайте

Не, господа, говорить "это плохой дизайн, потому что запросы неэффективны" я и сам могу. Но никто ведь не предложит альтернативы для случая, когда набор возможных полей у объекта действительно не известен по определению? Предложите более "умный" дизайн — я спасибо скажу.

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Не, господа, говорить "это плохой дизайн, потому что запросы неэффективны" я и сам могу. Но никто ведь не предложит альтернативы для случая, когда набор возможных полей у объекта действительно не известен по определению? Предложите более "умный" дизайн — я спасибо скажу.

XML — если объемы не гигантские. Другое дело, что далеко не все умеют его индексировать. Но ведь выбор SQLite — тоже часть дизайна, не так ли?

Также стоит обратить внимание на не-SQL (и возможно даже нереляционные) дивжки, приспособленные для хранения данных нерегулярной или разреженной структуры.
Например тот же ESE (aka "JET Blue") — кстати бесплатен (встроен в Windows).
(здесь, здесь)

Здравствуйте, wildwind, Вы писали:

ЗХ>>Не, господа, говорить "это плохой дизайн, потому что запросы неэффективны" я и сам могу. Но никто ведь не предложит альтернативы для случая, когда набор возможных полей у объекта действительно не известен по определению? Предложите более "умный" дизайн — я спасибо скажу.

W>XML — если объемы не гигантские. Другое дело, что далеко не все умеют его индексировать. Но ведь выбор SQLite — тоже часть дизайна, не так ли?

W>Также стоит обратить внимание на не-SQL (и возможно даже нереляционные) дивжки, приспособленные для хранения данных нерегулярной или разреженной структуры.
W>Например тот же ESE (aka "JET Blue") — кстати бесплатен (встроен в Windows).
W>(здесь, здесь)

Мммм... XML мне тут несимпатичен совершенно (объемы — тысячи, но могут быть и десятки тысяч объектов). Поскольку одно из условий — частая модификация свойств объектов (что приведет к перезаписи всего XML-я).

Вообще говоря, исходная постановка звучит так примерно:
* есть объекты, у них есть текстовые свойства (имя=значение)
* количество свойств у одного объекта — не ограничено (хотя реально, как правило, невелико)
* длина имени, длина значения — неограничены (или ограничены чем-нибудь большим); реально там будет как правило недлинные текстовые строки, но могут быть и очень длинные (например description=<описание объекта на 8 страниц>)

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

Вот. Внимание вопрос: какой движок тут подойдет /заметим, что дополнительное требование к движку — легковесность/

Здравствуйте, Зверёк Харьковский, Вы писали:

ЗХ>Мммм... XML мне тут несимпатичен совершенно (объемы — тысячи, но могут быть и десятки тысяч объектов). Поскольку одно из условий — частая модификация свойств объектов (что приведет к перезаписи всего XML-я).

Ну конечно я имел в виду не все в одном XML, а каждый объект в своем XML-е.

Здравствуйте, wildwind, Вы писали:

ЗХ>>Мммм... XML мне тут несимпатичен совершенно (объемы — тысячи, но могут быть и десятки тысяч объектов). Поскольку одно из условий — частая модификация свойств объектов (что приведет к перезаписи всего XML-я).

W>Ну конечно я имел в виду не все в одном XML, а каждый объект в своем XML-е.

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

Try 'Transform'? Not sure if your sql supports it... A bit of a vintage stuff...