Форум MySQL

>Кстати, как сделать, чтобы при этом отсчёт начинался с нулевого значения, а не с единицы?
>зачем? вас никоим образом не должен колебать идентификатор строки

Да он меня и не колебает вовсе...
Просто у меня в движке сайта используются таблицы тем и материалов (по темам, ессно).
Заполнил таблицы. Проверил работу движка, а потом решил в материалы помещать варианты главной страницы. Чтобы не нарушать идею работы алгоритма думал для них использовать нулевое значение поля связи с таблицей тем, где соответствующее поле с автоинкрементом. А меньше единицы уже никак...
Задачу-то я решил, но красота решения пострадала.

Так что вопрос, в общем, теоретический. Можно, конечно, перезагрузить содержимое таблиц заново с учётом упомянутого изменения.
Но удивило меня, что везде отсчёт с нуля начинается, а тут... Неожиданность, короче, для меня.

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

Возможно, я чего-то не понял...
Почему не использовать PK и autoincrement?

Кстати, как сделать, чтобы при этом отсчёт начинался с нулевого значения, а не с единицы?

да не все так просто
порядковый номер может сопадать для удаленных карточек
и удаленных кариточек может быть больше чем одна
( в крайнем случае в системе сейчас так есть )
Это придется с ними как то бодаться

нет не должен - ID это просто идентификатор записи в таблице он уникален по всей таблице.
первый столбец - это и есть номер
второй столбец - это идентификатор группы
а третий это ID Он по всей таблице уникален

Оп-па намек понял
нужен порядковый номер записи в группе теоретически тогда да
если брать индекс

PNum + номер записи в группе (для первой записи он всегда будет 1 ) то да вроде как неплохой выход

Спасибо за наводку что то я сразу ступил

В этой системе
PNum GroupID ID
1 X1 123
1 X1 124
1 X1 125
2 O1 126
2 O1 127
3 Y1 128
3 Y1 129
3 Y1 130
Вы для какого столбца выбираете номера? По приведенной в первом посте схеме? ID? А разве он не должен выглядеть так?
PNum GroupID ID
1 X1 1
1 X1 2
1 X1 3
2 O1 1
2 O1 2
3 Y1 1
3 Y1 2
3 Y1 3

Индекс тут не поможет

PNum GroupID ID
1 X1 123
1 X1 124
1 X1 125
2 O1 126
2 O1 127
3 Y1 128
3 Y1 129
3 Y1 130
все указанное выше правильно (для системы), теперь
вставляется ошибочный номер (тот который уже есть но с другим GroupID)
2 N1 131
Вот я не вижу тут какой идекс не даст этого сделать даже составной
Составной уникальный PNum+GroupID не даст вставить из первого списка уже вторую запись
но при этом ошибочную запись пропустит на ура.
А по поводу ускорения ну да помог бы не уникальный составной GroupID+ID если бы строился
запрос типа
SELECT MAX(ID) FROM T1 WHERE GROUP ID= ......
А в приведенном примере (т.е. по требованию к системе такого нет).
Ну что ж спасибо за диалог
Для себя сделал следующий выход на триггере до вставки определяется вариант номера с учетом того что есть в таблице (как это приведено в первом посте)
После чего делается Commit
и тут же выполняется хранимая функция (с передачей ей идентификатора записи),
которая делает проверку на дубликат если проверка прошла удачно, то возвращается присвоеннй номер. Если выявлен дубликат то делается UPDATE на новый Max(PNUM) уже в цикле по окончания выдается новый номер PNUM
Пока выход только такой.

Действительно можно построить индекс по двум полям... тем более в InnoDB индексы так устроены, что лучше использовать один индекс на таблицу (при этом выбирать самый толковый и часто используемый - это как раз ваш случай).

Однако, опять же не понятно, почему хотите добиться уникальности именно в пределах группы, а не таблицы. Я не спорю, есть такие задачи (правда очень редко и всеми правдами и неправдами стараются их вынести с физического столбца базы данных). Однако, если не менять условия скорее всего в плане производительности вы ничего лучше того, что в первом посте не придумаете... и тут кстати, индекс по двум полям вам может здорово пригодиться в плане ускорения MAX(PNum).

тогда нужно общий индекс на два поля

Я уже писал что проиндексировать не получится
т.к. PNUM не может быть уникален,
т.е. он может повторяться в пределах группы по GroupID
но при этом он не должен повторяться в разных GroupID