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

1) Для каждой схмы создается полностью изолированный набор данных. При созданиии новой схемы все общие данные копируются и в поле scheme_id проставляется нужное значение. Вся синхронизация между общими данными осуществляется программным способом. Этот вариант не очень удобен, слишком много дублирующихся данных, при чем их число возрастает на конкретную величину с каждой новой схемой. А если учесть, что на таблицу данных есть ссылки из других таблиц, то и там данные необходимо продублировать для новых записей. Но зато нет никаких проблем для работы внутри одной схемы. Всё изолировано: что хочешь - добавляй, редактируй, удаляй.

2) В таблицу Данные записывается данные без ссылок на scheme_id. Но есть таблица-связка, по которой собираются данные для каждой из схем. Здесь с общими данными попроще, потому как для каждой из схем из таблицы связки всё равно ссылаются на одну запись в таблице Данные. То есть не потребуется синхронизации в других схемах в случае изменения. Но опять же, в таблице-связке появляется куча дублирующей информации. Только теперь ее стало значительно меньше. При этом появляются проблемы при работе внутри схемы. При таких изменениях данных, которые недолжны коснуться других схем, необходимо это отслеживать и создавать новую запись в таблице данные - с измененными значениями и исправлять запись в таблице связке... Или удалять старую запись и создавать новую (что не особо принципиально).

3)
Данные
-----------
scheme_id
другие поля

Те данные, которые относятся ко всем схемам будут иметь scheme_id=NULL. Если появляются новые данные в конкретной схеме - то запись создается со ссылкой на соотв. схему. Исчезает потребность в дублировании , за исключением случаев, когда новые данные нужны не одной схеме, а нескольким. Но таких случаев очень мало. Можно, конечно, опять создать таблицу-связку и в нее помещать не все подряд ссылки на таблицу Данные, а только те, которые относятся к конкретной схеме, тогда описанную проблему можно обойти. Но остается проблема в отслеживании, когда изменения, производимые в одной схеме, не должны касаться другой, необходимо создавать новую запись с измененными данными, старую связку удалять и создавать новую.
Но это не самое неприятное при таком подходе. Новые данные добавить - без проблем. А вот как быть в случае, когда наоборот, какие-то данные из общей массы не нужны в конкретной схеме? Как быть в этом случае?
Решение в лоб, очень неэффективное: объявить эти данные не общими и сделать ссылку на эти данные из всех остальных схем, за исключением текущей. Но тогда утверждение типа авторза исключением случаев, когда новые данные нужны не одной схеме, а нескольким. Но таких случаев очень мало. становится неверным. В этом случае удобность последнего варианта схемы становится сомнительной.... Потому как в этом случае становится ооочень проблематично угадать, какие данные необходимо добавить в новую схему автоматом. А придумать другой вариант указать не показывать эти данные при такой схеме пока не придумалось. Может вы что-нибудь посоветуете?

В общем, идея у меня появилась следующего рода:
Таблица
Данные
________
id
scheme_id
etc.

SCHEME
_______
id
name

EXCLUDE - в такой-то схеме, такие-то данные не отображать
_________
Данные_id
scheme_id

И на основании этого есть несколько вопросов.
1) Что лучше: закрепить за общей схемой определенный ID, скажем, -1 или 0, или же разрешить в таблице Данные поле scheme_id оставлять NULL - и такие данные считать общими.
2) Какой запрос будет работать быстрее
или

softwarerПолагаю, Вам стоит четко сформулировать, что Вы называете "схема" и вообще описать решаемую задачу - описать в прикладных терминах, а не в терминах предполагаемого Вами решения.

А вам не понятна поставленная задача? Ну назовите вы это не схемой, а множеством.
Есть одно ОБЩЕЕ множество данных, объектов, ну в общем тоже не суть важно.
Хочу создать на основе него новое множество. бОльшая часть данных в новое множество попадет. Но может получиться и так, что в него попадут данные, которые не являются общими, а являются специфическими и нужны только в данном множестве. И наоборот, некоторые данные из общего множества совершенно не нужны в новом. И соответственно необходимо, чтобы можно было получить результат запроса:
Отберите все данные такого-то множества.

softwarerНет, мне не была понятна задача. И судя по отсутствию ответов, не только мне.

Странно. Но на мой взгляд на все ваши вопросы можно найти ответы в более ранних постах, разве что кроме этого:

softwarerЕсли так - вопрос в том, насколько произвольно распределение данных между этими множествами.
Отвечаю: заранее не предугадать попадет конкретное данное в схему или нет. Не существует заранее определенного алгоритма включения данных в схему\множество.
softwarerЯ бы постарался свести к следующему случаю:

1. Описано некоторое количество категорий, так, что каждая строка данных приписана к одной из категорий.
Ответ:
авторЕсть некоторые данные. И есть, не знаю, как правильнее назвать, пусть будут схемы данных. Среди данных есть общие для всех схем, при чем таких - подавляющее большинство. Но есть и данные, которые относятся только к конкретной схеме и в других схемах они не нужны.
Вы просто предлагаете ввести средний слой между данными и схемами и назвали их категориями... От этого проблема не ушла, а просто появилась другая. Например, должно жестко выполняться условие: "каждая строка данных приписана к одной из категорий". А появляется новая схема, в которой эта строка нужна, а все остальные, относящиеся к данной категории - нет. Нужно это данное либо включать в другую категорию (что требует пересмотра тех схем, куда уже была включена эта категория), либо создавать дубль и вписывать его в подходящую под новую схему категорию, либо заводить отделно новую категорию данных, которую включить во все нужные схемы. Если выбрать третий вариант, то смысл вводить категории, в которых будет по одной-две строчки становится очень сомнительным...

softwarer2. Схема описывается как набор категорий.

Соответственно, в строке данных делается поле категории, возможно ключом. Делается view или временная таблица, или политика ограничения доступа - что-то, что выдает доступные в настоящий момент категории (выбранную схему). Там, где нужно выбрать данные по схеме, данные просто join-ятся с этим списком категорий.
То, что вы предлагаете - по сути это 2) вариант решения, только попытались уменьшить количество дублей. Понятно, что категорий данных по-идее должно оказаться меньше и тогда при разбиении на схемы категорий, если одна и та же категория попадет в одну и ту же схему, то дублей будет меньше, чем если бы надо было показать, что все данные этой категории попадают в эту схему.
Но! Если раньше была проблема - как разбить данные на схемы, то теперь проблема в том, как разбить данные на категории да еще и соблюсти условие:
"каждая строка данных приписана к одной из категорий"

Кот МатроскинНе думали над наследованием схем? сначала создается базовая схема, вообще без данных. От нее наследуются остальные схемы. Для любой схемы можно найти схему, по сравнению с которой данные только добавляются. Тогда мы наследуем первую схему от второй и давляем специфичные данные по методу 3.
Если различия между схемами не очень большие - это имхо должно быть достатчно эффективно.
Это интересный вариант. Даже очень. И я размышлял над ним. Но он не совсем подходит, так как
авторзаранее не предугадать попадет конкретное данное в схему или нет. Не существует заранее определенного алгоритма включения данных в схему\множество.
Поэтому, например, понаследовал я одну схему от другой. А потом появляются данные, которые нужны в родителе, а в наследнике - не нужны. Нужно перестраивать дерево наследования? Или как-то еще выходить из этой ситуации... Данные поступают в систему фрагментарно и поэтому заранее сложно выстроить взаимозависимость. За исключением: Есть базовая или общая, и есть специфические, уточняющие базовую. Но уточнять они могут как добавляя к себе данные, так и исключая некоторые данные из общей схемы.

Не кажется ли вам, ModelR, что то, что вы предлагаете оооочень похоже на придложенный мной третий вариант решения с добавлением втрого поста. Только гораздо сложнее... На мой взгляд. Я так понимаю, у вас еще к тем трем таблицам должна быть еще

Данные
________
id
etc.

Конечно, логически представить то, что предлагаете вы, - проще. Ведь понятно, что в схему данные можно либо включить, либо исключить. И выделенная для этого отдельная таблица логически воспринимается адекватнее. Но зато запросы становятся к БД сложнее. И на мой взгляд выполняться они будут медленнее, а точнее дольше :-(

P.S. Все еще жду ответы на вопросы, заданные во втором посте:
авторИ на основании этого есть несколько вопросов.
1) Что лучше: закрепить за общей схемой определенный ID, скажем, -1 или 0, или же разрешить в таблице Данные поле scheme_id оставлять NULL - и такие данные считать общими.
2) Какой запрос будет работать быстрее

Кот Матроскин Вот, предположим, у нас есть схема A и унаследованная от нее схема B.
Появляются данные, которые нужны в А, но не нужны в B. Так?
Имхо напрашивающееся решение - не трогать ни A, ни B, породить от A
схему A1, добавить в нее новые данные и везде использовать A1 вместо A.
Поскольку дублирования нет, общие данные все равно продолжают лежать в A - никакого оверхеда не происходит,просто добавляются новые данные с ссылкой на новую схему.
Имхо так проще, чем с "вычитанием" данных - и структура понятнее, и запросы проще.

Без сомнения. Я же не говорю, что это неверный вариант. Я говорю о том, что мне это не совсем подходит.
Просто рассмотрим пример дальше: От B наследует C. Появляются данные, которые нужны в A1, B, но не нужны в С. Создавать наследника B1?
А кроме B от A наследует D. И те данные, которые нужны A, нужны и в D, в том числе и то, что не попало в B. Надо перенаследовать D от A1 или добавлять данные относительно A?
В общем эта структура действительно очень удобная в том случае, когда между схемами заранее можно установить связть типа "Родитель-Наследник". Когда эта связь не известна и устанавливается только на основе признака вложенности по текущим данным, то дерево наследования может сильно разрастись и работать с ним уже будет не удобно.

softwarerОт этого уходит (становится значительно менее актуальной) проблема скорости и сложности выборки.
Не уверен, что появление промежуточной таблицы в запросах даст дополнительную скорость. Это наверное всё-таки зависит от тех запросов, которые надо будет выполнять. И с Вами я согласен, что Ваша идея вполне жизнеспособна, но опять же, в данной ситуации она просто теряет смысл.

softwarerЭто эквивалентные проблемы. Если данные разбиты на схемы, их можно автоматически разбить и на уникальные категории (например, сделав категорию битовым вектором по затронутым схемам).
В том-то и дело, что данные еще не разбиты на схемы и нет строго формализованного алгоритма по их разбиению. Кроме того, смысла введения категорий, которые будут являться битовым вектором по затронутым схемам, просто не вижу. Если раньше схема определялась набором категорий, то теперь выходит, что категория определяется через схемы...

В общем, спасибо всем за стоящие советы, но пока воспользоваться ими в данном конкретном случае не представляется возможным.

EstetsДействительняа проблема в поставленной задаче это
А вот как быть в случае, когда наоборот, какие-то данные из общей массы не нужны в конкретной схеме? Как быть в этом случае?

Но я бы лишний раз подумал над тем а нужно ли это действительно? Если это общие данные то они должны быть общими. А если нет то они должны быть локальными для всех кому это надо.

Это действительно нужно. Почему же вы думаете, что специфика тех же мастерских состоит лишь в том, чтобы в них было что-то дополнительно? Почему, например, заведующий складом новой мастерской не вправе отказаться от тех же саморезов 3x15, которые по идее должны быть в каждой мастерской, и не потребовать в замен саморезы 4x15 в силу специфики производимых изделий? Если следовать вашей логике, то эти саморезы должны лечь мертвым грузом, потому что в программе заложено, что это ОБЩИЙ материал и всё равно, что он здесь не понадобится или же из-за одной единственной мастерской исключить саморезы 3х15 из общих материалов и каждой новой мастерской не давать эти саморезы сразу, а ждать, когда будет сделан заказ "специфического" материала. Во втором случае:
авторРешение в лоб, очень неэффективное: объявить эти данные не общими и сделать ссылку на эти данные из всех остальных схем, за исключением текущей. Но тогда утверждение типа
за исключением случаев, когда новые данные нужны не одной схеме, а нескольким. Но таких случаев очень мало.
становится неверным. В этом случае удобность последнего варианта схемы становится сомнительной.... Потому как в этом случае становится ооочень проблематично угадать, какие данные необходимо добавить в новую схему автоматом.

EstetsЕще раз могу сказать о том что решение задачи может быть оптимальным только в данном конкретном случае. Общих решений не бывает, или реализация их требует огромных затрат.
Я и не требовал общего решения и вроде назвал вполне конкретные условия и ограничения:
авторЕсть некоторые данные. И есть, не знаю, как правильнее назвать, пусть будут схемы данных. Среди данных есть общие для всех схем, при чем таких - подавляющее большинство. Но есть и данные, которые относятся только к конкретной схеме и в других схемах они не нужны.
авторЕсть базовая или общая [схемы], и есть специфические, уточняющие базовую. Но уточнять они могут как добавляя к себе данные, так и исключая некоторые данные из общей схемы.

И задача не состоит в распространении справочника.
Разграничивать права доступа к каждой записи таблицы в БД на основе ролей... По-моему, это уже лишко. Не кажется вам проще вариант с таблицей EXCLUDE?
Я пока всё же остановился на этом варианте. Если кто понимает, в чем его минусы или потенциальные сложности - поделитесь мыслями ;-)