Приветствую всех.
В различных СУБД есть возможность обеспечить вставку уникальных значений в определённые столбцы таблиц. СУБД своими средствами проверит и обеспечит что ни одно значение в столбце таблицы не повторится дважды. Это банально и широко известно. А вот, что, если надо обеспечить уникальность данных, но не во всей таблице, а только в пределах определённой части или “секции” таблицы? К примеру, у нас в таблице собраны номера домов. Пока у нас в таблице дома с одной улицы - их номера уникальны. А если у нас больше одной улицы - номера домов на разных улицах могут повторятся. Итак, вопрос…
Кто нибудь знает, если существует способ средствами СУБД “разбить” таблицу на “секции” (по улицам, как в приведённом примере) и обеспечить уникальность данных в пределах секции? Может быть, с помощью составного ключа? Такое возможно в SQLight или какой-то другой СУБД? Или, в такой ситуации, для контроля за “секционной” уникальностью данных нет вариантов что-то использовать кроме прикладной программы, которая обеспечивает пользователю доступ в БД?

> Может быть с помощью составного ключа?

Совершенно верно. Создаёшь составной уникальный индекс и всё будет правильно работать.

Rodegast
Создаёшь составной уникальный индекс и всё будет правильно работать.

Спасибо, что укрепили мои надежды. С ходу нагуглить инструкции не смог. Буду продолжать копать и экспериментировать в этом направлении.

Ещё есть частичные индексы. В такой индекс попадут только те данные которые соответствуют определённому условию. Например с его помощью можно сделать уникальными только чётные дома.

Rodegast
CREATE UNIQUE INDEX имя_индекса ON таблица (Дом, Улица);

Неожиданная формула, неожиданный подход. У меня в голове сложился стереотип: в качестве индекса надо использовать отдельный столбец, в котором тупо нумеруются записи. А у Вас… Слом моих стереотипов. А в самом деле, если у нас есть уникальные данные, почему бы в качестве индекса не использовать эти данные?
Завтра буду обдумывать такой вариант. Спасибо.

Ещё есть частичные индексы.

Тоже интересный вариант. Но в моём случае не подходит.

Alex.Pro.
Может быть, с помощью составного ключа?

А что тебе мешает сделать составной первичный ключ?

Это либо пары (улица, дом) без отдельного отношения, либо тройки (id, улица, дом) в отдельном отношении, где id делается для того, чтобы потом внешние ключи делать, состоящие из одного атрибута, а не из двух.

При этом ты в первом случае накладываешь рестрикцию уникальности на составной первичный ключ, просто обозначив его первичным ключом в СУБД. А во втором случае ты накладываешь рестрикцию уникальности на два атрибута из трёх атрибутов сразу, и это в каких-то СУБД можно будет сделать, а в каких-то нет.

Alex.Pro.
Такое возможно в SQLight или какой-то другой СУБД?

Да СУБД все разные в плане возможностей. Не меняется только одно - теория баз данных, которая для всех СУБД одинакова. Вот именно ей и надо следовать.

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

py.user.next
что мешает просто сделать составной первичный ключ?

Больше всего мне мешает недостаток знаний и опыта.
Часть БД и программы к ней уже готова. (Без предварительной проработки проекта. Архитектура, в общих чертах, была продумана в голове и уточняется по ходу дела в процессе написания кода) Первичный ключ (id) был создан, как бы, “по традиции”. Столбец (дом) изначально был сделан уникальным, но по ходу дела, стало видно что это слишком ограничивает таблицу. Теперь составлять первичный ключ из трёх значений, при этом добиваться независимой уникальности для разных частей ключа - не вижу смысла. Это сложно и сомневаюсь что SQLight такое сможет. Да и необходимости собирать тройки тоже не наблюдаю. Собираюсь дополнительно к первичному ключу сделать ещё составной уникальный ключ из пар (улица, дом). Будут в таблице сразу три ключа: первичный, внешний (id из отдельной таблицы улиц) и составной. Надеюсь что SQLight с таким справится (DB Browser for SQLight что-то такое позволяет) и такое решение позволит мне получить жёсткий контроль уникальности номеров домов в пределах любой улицы.
Пойду позанимаюсь практикой. О результатах расскажу. ;-)

Alex.Pro.
недостаток знаний

Этого у тебя хватает. Если думаешь, что базы данных простая тема, то немножко заблуждаешься. Да, они не требуют ничего умного там прямо, высокой математики, но там много нюансов и много всяких приёмов и правил, выработанных со временем. Если ты этого всего не знаешь, то это твои грабли. Ты просто будешь попадать в ловушки.

А что такое реляционная база данных? Ты не знаешь. Слово “реляционное” - это что, это о чём речь идёт? Так вот в Интернете много таких незнающих, которые ещё и статьи пишут. Ты потом по этим статьям учишься безграмотным и впитываешь всю эту тупизну оттуда. В итоге у тебя получается каша в голове. Ну это когда якобы ты всё знаешь и оно всё простое прям, только вот у тебя ничего не получается сделать.

Поэтому фильтруй информацию. И учись классической теории.

py.user.next
Этого у тебя хватает.

Ну да, согласен. Недостатков у меня хватает с избытком.
Да, я думаю что БД - это просто. По крайней мере, пока смотришь со стороны на грамотно построенную БД. Всё гениальное - просто!
Реляционные БД - это относительно просто и понятно. Наверное, поэтому реляционные БД распространены намного шире чем иерархические, графовые, ассоциативные и пр. разновидности БД. Для моих нужд реляционной БД вполне достаточно. И реализации СУБД в виде SQLight пока достаточно.
Теорию, конечно, знать нужно. Вопрос только, на каком уровне необходимо знать теорию? Труды Тьюринга, фон Неймана и Вирта я штудировать не собираюсь. Даже работы основателя Симантек (как там его звали?) и разработчика СУБД Q&A, прародителя SQL, тоже изучать желанием не горю. Тем более что абстрактная теория без реальной практики - бесполезна. Кое-что я знаю. Теперь это кое-что попытаюсь применить на практике. По мере необходимости буду подтягивать теорию. А грабли и ловушки помогут теорию закрепить.

Alex.Pro.
Да, я думаю что БД - это просто.

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

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

Почему я и предлагаю тебе обратиться к теории, прежде чем приступать к реализации. Ты основ не знаешь, потому что начитался каких-то статей от “экспертов” с каких-то хабрахабров и прочих псевдоисточников подобного уровня.