У меня есть дочерняя таблица с именем case_parties
, состоящая из имени и адреса каждого истца и ответчика в судебных делах.Добавление скрипта sql с автоматическим добавлением
В столбцах таблицы включают в себя:
case_id
, который является внешним ключом к родительской таблицеparty_type
, который кодированное значение полей 1 или 2 (1 с указанием истца и 2, указывающим, ответчик). Оговорка в том, что в каждом судебном деле не всегда есть только один истца и один ответчик. Часто в одном случае есть несколько истцов и или нескольких обвиняемых. В любом случае может быть от 1 до 1000 + истцов и ответчиков. Я создал новую колонку, давайте назовите ееparty_id
иSET
сCONCAT
на столбцахcase_id
иparty_type
. Поэтому сопоставление строк в этом столбце включает либо всех истцов, либо всех подсудимых в заданныйcase_id
.
Чтобы создать простой уникальный ключ для каждой строки, я хочу, чтобы запустить скрипт, который добавляет автогенерируемый порядковый номер или буквы в конец совпадающего party_id
поля. Например, если в одном и том же судебном деле есть 4 истца, теперь имеется 4 столбца с соответствующими значениями полей party_id
, причем последний символ равен 1, представляющий сторону, является истцом;
Я хочу добавить инкремент, чтобы каждый столбец был уникальным, а последние две цифры из четырех строк отображали бы что-то вроде этого: «1A», «1B», «1C», «1D» или «1- 1 "," 1-2 "," 1-3 "," 1-4 ", ... и т. Д. Я думаю, что добавление инкрементных чисел может быть проще, чем добавление дополнительных букв. В этом случае никакие другие значения столбцов индивидуально или коллективно не создают эффективный составной индекс. Я ищу помощь с автоматическим увеличением соответствующих значений столбцов и очень ценю любую помощь. Спасибо.
Я не думаю, что это сделало бы разумное решение разницы, но тип атрибута «party_id» - VARCHAR, а результирующий или отредактированный столбец, который будет однозначно идентифицировать каждую отдельную сторону, также должен быть VARCHAR. – pbnyc
Почему он должен быть VARCHAR? в идеале вы хотите, чтобы база данных обрабатывала уникальность для вас с помощью первичного ключа. – leeor
Поскольку большое количество идентификаторов case id содержит буквы, а идентификационный номер довольно длинный. Я знаю, что длинные первичные ключи не рекомендуются, у меня нет выбора в этой ситуации. Кроме того, это просто производственная база данных, которая будет использоваться для извлечения необработанных данных, которые будут превращены в более укомплектованные наборы данных. Так что я не очень беспокоюсь о производительности в этой производственной БД. – pbnyc