Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / вопрос по serial / 12 сообщений из 12, страница 1 из 1
18.12.2008, 05:13
    #35721428
sneer
sneer
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вопрос по serial
Есть такой тип serial. Вроде как он предназначен для создания id. Удобно в isert default указал и он сам нумерует. Проблемный самый обыкновенный пример. создаём первые сто полей. Последний id = 101 удаляем эти сто полей. Первый id = 102. И т.д. как мне сделать так что бы значения были плотные. удалил пять значений из середины потом вставил 10 значений оно вставило с id удалённых пяти и пять новых. Для меня это критично. Пример реальной жизни что бы не городить лишнее поле человек вводит id товара. Товаров не много и хотелось бы id не больше сотни то есть двузначные. Причина - низкая квалификация рабочего + специфические условия труда.Только подошёл к изучению тригеров. Если поможете советом буду рад.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.12.2008, 07:07
    #35721457
ДБ
ДБ
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вопрос по serial
sneer...serial тут не помощник. Его хорошо использовать для суррогатных ключей, а для непрерывной нумерации он не подходит.
Поищите ответ на свой вопрос на форуме "Проектирование БД"
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.12.2008, 11:08
    #35721753
assa
assa
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вопрос по serial
ДБ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, 18:59
    #35723261
Sad Spirit
Sad Spirit
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вопрос по serial
sneerПример реальной жизни что бы не городить лишнее поле человек вводит id товара. Товаров не много и хотелось бы id не больше сотни то есть двузначные. Причина - низкая квалификация рабочего + специфические условия труда.
Херня это, а не пример реальной жизни. Что будет с низкоквалифицированным рабочим, когда он при специфических условиях труда введёт по привычке двузначный id товара, который уже удалили и заменили новым?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.12.2008, 23:44
    #35723569
sneer
sneer
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вопрос по serial
Sad SpiritsneerПример реальной жизни что бы не городить лишнее поле человек вводит id товара. Товаров не много и хотелось бы id не больше сотни то есть двузначные. Причина - низкая квалификация рабочего + специфические условия труда.
Херня это, а не пример реальной жизни. Что будет с низкоквалифицированным рабочим, когда он при специфических условиях труда введёт по привычке двузначный id товара, который уже удалили и заменили новым?
Популярный товар(то есть номера которого он знает на наизусть) редко удаляется да и вообще специфика такова что лимит в 100 наименований будет превышен очень не скоро. По теме как сделать немного подумаю ещё как лучше и напишу.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
19.12.2008, 02:59
    #35723641
sneer
sneer
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вопрос по serial
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, 10:07
    #35723866
LeXa NalBat
LeXa NalBat
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вопрос по serial
нашлось

Gapless Sequences for Primary Keys

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

Gapless Sequences for Primary Keys

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

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

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

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

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

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


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