ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / вопрос по serial
12 сообщений из 12, страница 1 из 1
вопрос по serial
    #35721428
sneer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sneer
Гость
Есть такой тип serial. Вроде как он предназначен для создания id. Удобно в isert default указал и он сам нумерует. Проблемный самый обыкновенный пример. создаём первые сто полей. Последний id = 101 удаляем эти сто полей. Первый id = 102. И т.д. как мне сделать так что бы значения были плотные. удалил пять значений из середины потом вставил 10 значений оно вставило с id удалённых пяти и пять новых. Для меня это критично. Пример реальной жизни что бы не городить лишнее поле человек вводит id товара. Товаров не много и хотелось бы id не больше сотни то есть двузначные. Причина - низкая квалификация рабочего + специфические условия труда.Только подошёл к изучению тригеров. Если поможете советом буду рад.
...
Рейтинг: 0 / 0
18.12.2008, 05:13
| Ответить | Цитировать | Написать  
вопрос по serial
    #35721457
ДБ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ДБ
Гость
sneer...serial тут не помощник. Его хорошо использовать для суррогатных ключей, а для непрерывной нумерации он не подходит.
Поищите ответ на свой вопрос на форуме "Проектирование БД"
...
Рейтинг: 0 / 0
18.12.2008, 07:07
| Ответить | Цитировать | Написать  
вопрос по serial
    #35721753
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
assa
Участник
ДБsneer...serial тут не помощник. тут скорее нужен ф-л поиска пропусков.
обычно это просто что-то типа (не в точности, но примерно)
Код: plaintext
1.
2.
3.
4.
5.
SELECT t.id+ 1  FROM tab t
  LEFT JOIN tab n
  ON t.id+ 1  = n.id
WHERE n.id IS Null
 ORDER BY t.id
 LIMIT  1

забавно что вот такое
Код: plaintext
1.
2.
3.
4.
5.
SELECT t.id+ 1  FROM tab t
  LEFT JOIN tab n
  ON t.id = n.id- 1 
WHERE n.id IS Null
 ORDER BY t.id
 LIMIT  1
будет считаться по другому плану, (у меня - много дольше).

ну и для пропусков с начала (тако же как для получения последнего) нужны еще и
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SELECT t.id
,(SELECT t.id FROM  tabla t ORDER BY id  LIMIT  1 ) as min_id
,(SELECT t.id FROM  tabla t ORDER BY id DESC  LIMIT  1 ) as max_id
 FROM tabla t
  LEFT JOIN tabla n
  ON (t.id+ 1  = n.id)
  WHERE n.id IS Null
ORDER BY t.id
 LIMIT  1
теперь, если прикинуть, как у этой бодяги будет с транзакционностью и т.п.... - скорее всего надумаем наплевать на вышесказанное
, и придём к идее хранения таблички пропусков, пополняемой/прорежаемой триггерами. + (вероятно) счетчик(и) - в кач-ве внетранзакционной переменной(ых) для обмена данными (о резервировании) между конкурирующими транзакциями.
Как-то так.
...
Рейтинг: 0 / 0
18.12.2008, 11:08
| Ответить | Цитировать | Написать  
вопрос по serial
    #35723261
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
sneerПример реальной жизни что бы не городить лишнее поле человек вводит id товара. Товаров не много и хотелось бы id не больше сотни то есть двузначные. Причина - низкая квалификация рабочего + специфические условия труда.
Херня это, а не пример реальной жизни. Что будет с низкоквалифицированным рабочим, когда он при специфических условиях труда введёт по привычке двузначный id товара, который уже удалили и заменили новым?
...
Рейтинг: 0 / 0
18.12.2008, 18:59
| Ответить | Цитировать | Написать  
вопрос по serial
    #35723569
sneer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sneer
Гость
Sad SpiritsneerПример реальной жизни что бы не городить лишнее поле человек вводит id товара. Товаров не много и хотелось бы id не больше сотни то есть двузначные. Причина - низкая квалификация рабочего + специфические условия труда.
Херня это, а не пример реальной жизни. Что будет с низкоквалифицированным рабочим, когда он при специфических условиях труда введёт по привычке двузначный id товара, который уже удалили и заменили новым?
Популярный товар(то есть номера которого он знает на наизусть) редко удаляется да и вообще специфика такова что лимит в 100 наименований будет превышен очень не скоро. По теме как сделать немного подумаю ещё как лучше и напишу.
...
Рейтинг: 0 / 0
18.12.2008, 23:44
| Ответить | Цитировать | Написать  
вопрос по serial
    #35723641
sneer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sneer
Гость
assaДБsneer...serial тут не помощник. тут скорее нужен ф-л поиска пропусков.
обычно это просто что-то типа (не в точности, но примерно)
Код: plaintext
1.
2.
3.
4.
5.
SELECT t.id+ 1  FROM tab t
  LEFT JOIN tab n
  ON t.id+ 1  = n.id
WHERE n.id IS Null
 ORDER BY t.id
 LIMIT  1

забавно что вот такое
Код: plaintext
1.
2.
3.
4.
5.
SELECT t.id+ 1  FROM tab t
  LEFT JOIN tab n
  ON t.id = n.id- 1 
WHERE n.id IS Null
 ORDER BY t.id
 LIMIT  1
будет считаться по другому плану, (у меня - много дольше).

ну и для пропусков с начала (тако же как для получения последнего) нужны еще и
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SELECT t.id
,(SELECT t.id FROM  tabla t ORDER BY id  LIMIT  1 ) as min_id
,(SELECT t.id FROM  tabla t ORDER BY id DESC  LIMIT  1 ) as max_id
 FROM tabla t
  LEFT JOIN tabla n
  ON (t.id+ 1  = n.id)
  WHERE n.id IS Null
ORDER BY t.id
 LIMIT  1
теперь, если прикинуть, как у этой бодяги будет с транзакционностью и т.п.... - скорее всего надумаем наплевать на вышесказанное
, и придём к идее хранения таблички пропусков, пополняемой/прорежаемой триггерами. + (вероятно) счетчик(и) - в кач-ве внетранзакционной переменной(ых) для обмена данными (о резервировании) между конкурирующими транзакциями.
Как-то так.


Я если чес не понял твоих запросов. Мог бы поподробнее объяснить. Я про запросы поиска пропусков.
...
Рейтинг: 0 / 0
19.12.2008, 02:59
| Ответить | Цитировать | Написать  
вопрос по serial
    #35723866
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
нашлось

Gapless Sequences for Primary Keys

creating "a perfect sequence" column
...
Рейтинг: 0 / 0
19.12.2008, 10:07
| Ответить | Цитировать | Написать  
вопрос по serial
    #35724584
Kruchinin Pahan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kruchinin Pahan
Участник
LeXa NalBatнашлось

Gapless Sequences for Primary Keys

creating "a perfect sequence" column
Да ну нафиг. Первая ссылка предлагает вообще не удалять данные.

Не, надо как assa предлагает в общем виде. Только таблицу придется блокировать AccessExclusive, пока генерится id-шник.
...
Рейтинг: 0 / 0
19.12.2008, 13:27
| Ответить | Цитировать | Написать  
вопрос по serial
    #35724922
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cane Cat Fisher
Участник
Тут путается два вопроса.

Первый - суррогатный ключ. Используйте serial, и пусть хоть до миллиона дойдет. Суррогатный ключ по определению никогда не предъявляется пользователю. Пользователь его не видит, и не вводит значений, которые с ним сравниваются. Назовем это поле "ID".

Второй - удобная идентификация товара персоналом. Назовем это поле "Код" (CODE). Это пользовательские данные о товаре, такие же как название. Генерите его любым удобным алгоритмом с обработкой дырок. Могу порекомендовать держать две отдельных таблички. Одна с последним максимальным выданным номером, другая - с перечнем свободных номеров (пополняется при удалении записей). При добавлении нового товара сперва искать в таблице свободных номеров, и брать оттуда, удаляя запись, если нет - увеличивать последний выданный номер во второй таблице и брать его. Разумеется, не забывать блокировать таблицу последнего выданного номера.
...
Рейтинг: 0 / 0
19.12.2008, 15:27
| Ответить | Цитировать | Написать  
вопрос по serial
    #35725398
sherzod_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sherzod_
Участник
насчет херни это точно
а как насчет НЕиспользования физического удаления
...
Рейтинг: 0 / 0
19.12.2008, 18:09
| Ответить | Цитировать | Написать  
вопрос по serial
    #35725438
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
assa
Участник
sherzod_насчет херни это точно
а как насчет НЕ использования физического удаленияпо первой ссылке какая-то муть почти на эту тему. только там 2 таблички, одна, с номерами, вроде иммено что неудаляемая

по части "НЕ использования физического удаления" - есть еще незакоммиченные транзакции. они тоже делают дырки в счетчиках. Если откатились после вызова сиквенса. Т.е. на каждой транзакции придется проверять состояние счетчика (что он равен максимальному значению в таблице +1) и (пытаться) откатывать сиквенс "вручную" (если он таки не равен - что не обязательно говорит об откаченных транзах, но, возможно, о незакоммиченных) - т.е. неизбежны проблемы (т.к. мы теряем транзакционную независимость сиквенса) .
...
Рейтинг: 0 / 0
19.12.2008, 18:39
| Ответить | Цитировать | Написать  
вопрос по serial
    #35727337
assa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
assa
Участник
assa по части "НЕ использования физического удаления" - есть еще незакоммиченные транзакции. они тоже делают дырки в счетчиках.да, это можно решить заблаговременным резервированием номеров пачками, вместо использование счетчика под генерацию номеров.

Таки с неудалением вроде-бы вырисовывается простенько и со вкусом.
...
Рейтинг: 0 / 0
22.12.2008, 11:30
| Ответить | Цитировать | Написать  
12 сообщений из 12, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / вопрос по serial
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]