|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
Добрый день. SQL 2016 Standart SP2 Есть следующая структура: Tab1 (ID1 bigint primary key, <прочие поля 1>) Tab2 (ID2 bigint primary key, ID1 bigint (ссылка на Tab1),<прочие поля 2>) Tab3 (ID3 bigint primary key, ID2 bigint (ссылка на Tab2),<прочие поля 3>) Так хранятся данные по платежам физических лиц. Эта структура уже есть и работает, т.е. пользователи уже работают с физическим лицам через интерфейс А также поля ID1, ID2, ID3 передаются во внешнюю систему для связи этой системы и внешней (во внешней системе сохранены ID1, ID2, ID3 и по ним идет часть обращений в эту систему) Нужно в добавить хранение платежей по юридическим лицам. Планируем делать так же. Tab4 (ID4 bigint primary key, <прочие поля 4>) Tab5 (ID5 bigint primary key, ID4 bigint (ссылка на Tab4),<прочие поля 5>) Tab6 (ID6 bigint primary key, ID5 bigint (ссылка на Tab5),<прочие поля 6>) Ну нужно обеспечить уникальность среди пар ID1 и ID4, ID2 и ID5, ID3 и ID6. Т.е. чтобы значение поля ID1 в Tab1 не повторялось в поле ID4 в Tab4. Т.е. надо соблюсти уникальность на 2 таблицы и не испортить то что уже работает с учетом минимизации затрат на изменения. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 09:37 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1, Начните ID4 c 1000000000000 К тому времени, когда ID1 его догонит вы будете на пенсии ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 09:41 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1 Ну нужно обеспечить уникальность среди пар ID1 и ID4, ID2 и ID5, ID3 и ID6. Т.е. чтобы значение поля ID1 в Tab1 не повторялось в поле ID4 в Tab4. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 09:42 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
andy st К тому времени, когда ID1 его догонит вы будете на пенсии ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 09:43 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
alexeyvg andy st К тому времени, когда ID1 его догонит вы будете на пенсии Надо быть оптимистом :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 09:52 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
andy st mih.dim1, Начните ID4 c 1000000000000 К тому времени, когда ID1 его догонит вы будете на пенсии Спасибо. Я тоже склоняюсь к этому варианту. Хотел узнать есть ли другие варианты. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 09:59 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
Я так понимаю для полной уверенности что ничего не пересечется (мы отдадим систему на откуп заказчику через пару лет), чтобы кривые ручки их админа случайно напрямую не вставили значение или что то подобное, нужно еще и ограничения поставить? create Table tab1 (ID1 bigint identity(1,1)) ALTER TABLE tab1 ADD CONSTRAINT Id_tab1 CHECK (ID1 <1 000 000 000 000); create Table tab4 (ID4 bigint identity(1 000 000 000 000,1)) ALTER TABLE tab4 ADD CONSTRAINT Id_tab4 CHECK (ID4 >=1 000 000 000 000); вопрос только в том, а не создаст ли это существенную нагрузку на систему для проверки, если в 1 сек могут добавиться около 100 тыс записей в каждую из таблиц? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 10:09 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1, грамотный админ удалит ограничения и сбросит identity в 1 на обеих таблицах ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 10:15 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
А еще можно использовать отрицательные значения и декремент: identity(-1,-1). ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:00 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
andy st mih.dim1, грамотный админ удалит ограничения и сбросит identity в 1 на обеих таблицах Он еще и злодей. Мне нужна защита от случайных изменений по не знанию. Если он целенаправлено "гадит", то он и базу удалит без проблем. Вопрос был в увеличении нагрузки на сервер. Кто нить уже делал подобные ограничения и как это повлияло на работу? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:12 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1 если в 1 сек могут добавиться около 100 тыс записей в каждую из таблиц? Если добавляется 100 тысяч записей в секунду, то думать надо совсем о других вещах. Или более 4 месяцев работы не требуется? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:15 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1 Я так понимаю для полной уверенности что ничего не пересечется (мы отдадим систему на откуп заказчику через пару лет), чтобы кривые ручки их админа случайно напрямую не вставили значение или что то подобное, нужно еще и ограничения поставить? вопрос только в том, а не создаст ли это существенную нагрузку на систему для проверки, если в 1 сек могут добавиться около 100 тыс записей в каждую из таблиц? Нагрузку не создаст, они проверяются быстро. Только будет проблема с балк-загрузкой с отключёнными чек-констрейнами. Если таковые загрузки есть. Тут нужно быть особенно внимательным. Притом нельзя отключить только FK, можно только все чек- и форейн- констрейны. А проверять FK при балке - долго. Да и вообще, по умолчанию констрейны не проверяются. Так что, ещё раз, тут требуется повышенная внимательность - не давайте делать импорт джуниорам :-). Alibek B. А еще можно использовать отрицательные значения и декремент: identity(-1,-1). ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:17 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
alexeyvg Это вариант реализации разделения по диапазонам, только не такой удобный, с недостатками. Если нужно разделить только на два сегмента, то такого способа может оказаться достаточно. А иногда это даже бывает удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:19 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1, Лучше в Tab1 добавить поле на справочник "юрик/физик/инопланетянин/.." и по нему разруливать А то после Tab7/8/9 и Tab10/Tab11/Tab12 всё будет некрасиво выглядеть ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:24 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
Alibek B. alexeyvg Это вариант реализации разделения по диапазонам, только не такой удобный, с недостатками. Если нужно разделить только на два сегмента, то такого способа может оказаться достаточно. А иногда это даже бывает удобно. Да только на 2 таблицы ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:26 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
andy st mih.dim1, Лучше в Tab1 добавить поле на справочник "юрик/физик/инопланетянин/.." и по нему разруливать А то после Tab7/8/9 и Tab10/Tab11/Tab12 всё будет некрасиво выглядеть проясню ситуацию: Tab1 - сейчас для для физиков содержит 15 полей (int,bigint,varchar) Если добавить в нее и хранение юриков, то нужно добавить еще 8 полей. И получиться ситуация: 9 общих полей, 6 заполнены только для физиков, 8 только для юриков. С Tab3 - всего 6 полей, из них общих для юриков и физиков только 1. Итог, если добавить все в одну структуру: 1 общее поле, 5 полей будет заполнено только для физиков, 7 полей только для юриков. Поэтому и было принято решение делить на разные таблицы. К тому же нужно и по доступу их потом делить. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:35 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1 Alibek B. пропущено... Если нужно разделить только на два сегмента, то такого способа может оказаться достаточно. А иногда это даже бывает удобно. Да только на 2 таблицы Например, часто нужна сортировка по инкрементному ID, индексы будут по разному работать, в интерфейсе отрицательные ID будут мельтешить. Плюс будет привычка к проверке +-. А если появится третья группа таблиц? Типа, третий поставщик, со своими ID? Или ещё какое то разделение... Я бы делал диапазоны вообще с ведущей цифрой: 1000000000000 - первый диапазон 2000000000000 - втопрой диапазон 3000000000000 - ... ... Они будут везде одинаково показываться, при этом по первой цифре можно видеть группу. andy st mih.dim1, Лучше в Tab1 добавить поле на справочник "юрик/физик/инопланетянин/.." и по нему разруливать А то после Tab7/8/9 и Tab10/Tab11/Tab12 всё будет некрасиво выглядеть ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:44 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1 проясню ситуацию: Tab1 - сейчас для для физиков содержит 15 полей (int,bigint,varchar) Если добавить в нее и хранение юриков, то нужно добавить еще 8 полей. И получиться ситуация: 9 общих полей, 6 заполнены только для физиков, 8 только для юриков. С Tab3 - всего 6 полей, из них общих для юриков и физиков только 1. Итог, если добавить все в одну структуру: 1 общее поле, 5 полей будет заполнено только для физиков, 7 полей только для юриков. Таблица с общими атрибутами Таблицы расширенных атрибутов, со связкой 1-1 к главной. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:45 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1, Можно без деления на диапазоны и проверок. Примерно так Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 11:45 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
alexeyvg mih.dim1 проясню ситуацию: Tab1 - сейчас для для физиков содержит 15 полей (int,bigint,varchar) Если добавить в нее и хранение юриков, то нужно добавить еще 8 полей. И получиться ситуация: 9 общих полей, 6 заполнены только для физиков, 8 только для юриков. С Tab3 - всего 6 полей, из них общих для юриков и физиков только 1. Итог, если добавить все в одну структуру: 1 общее поле, 5 полей будет заполнено только для физиков, 7 полей только для юриков. Таблица с общими атрибутами Таблицы расширенных атрибутов, со связкой 1-1 к главной. Да так хотели первоначально, но вариант не понравился тем что нужно много менять по существующим операциям (80% операций в системе), а также, разделяя на 2 таблицы, мы уменьшаем нагрузку на таблицу (TAb1 самая нагруженная по вставке данных). ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 12:12 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
mih.dim1 alexeyvg пропущено... Для этого делают структуру: Таблица с общими атрибутами Таблицы расширенных атрибутов, со связкой 1-1 к главной. Да так хотели первоначально, но вариант не понравился тем что нужно много менять по существующим операциям (80% операций в системе) Притом даже внедрение (обычно оно длительное, не одномоментное) новой функциональности на проде можно делать без риска поломать работающую (приносящую профит бизнесу) систему. Только нужно помнить, что вам всё равно придётся программировать работу с новыми таблицами, так что над оценкой трудоёмкости этих 2х вариантов нужно ещё поработать. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 12:18 |
|
Уникальный ключ на 2 таблицы.
|
|||
---|---|---|---|
#18+
alexeyvg mih.dim1 пропущено... Да так хотели первоначально, но вариант не понравился тем что нужно много менять по существующим операциям (80% операций в системе) Притом даже внедрение (обычно оно длительное, не одномоментное) новой функциональности на проде можно делать без риска поломать работающую (приносящую профит бизнесу) систему. Только нужно помнить, что вам всё равно придётся программировать работу с новыми таблицами, так что над оценкой трудоёмкости этих 2х вариантов нужно ещё поработать. Это ясно. Спасибо всем за помощь. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2020, 16:53 |
|
|
start [/forum/topic.php?fid=46&msg=39934508&tid=1686380]: |
0ms |
get settings: |
11ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
35ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 324ms |
total: | 453ms |
0 / 0 |