|
|
|
|
|
для: Trianon
(10.05.2009 в 12:36)
| | >почему же? Добавление новой строки как раз расширяет область определения позиции на один элемент. Здесь всё в порядке.
Если вводится новый элемент, число уникальный позиций увеличивается. Если будем принимать во внимание требование о неизменности множества значений позиций, мы не сможем добавлять новые элементы.
>Проверку уникальности можно вообще не вводить. Поле неключевое.
Неключевое, но уникальность и неотрицательность позволит избежать потенциальных ошибок в коде программ по сортировке и другим операциям с этой таблицей.
Более того, база данных уже может быть спроектирована до нас определённым образом (при этом никак нельзя будет упрекнуть проектировщиков в том, что они сделали поле уникальныи и неотрицательным). А в нашу компетенцию может входить разработка клиентской части и не более того.
>Вы уж выберите что-нибудь одно.[/i]
Выбираю неключевое, но уникальное и неотрицательное поле. | |
|
|
|
|
|
|
|
для: Cyrax
(10.05.2009 в 12:24)
| | >>не может выходить за множество номеров имеющихся строк.
>И тем самым исключить возможность добавления новых элементов в таблицу ?
почему же? Добавление новой строки как раз расширяет область определения позиции на один элемент. Здесь всё в порядке.
>>В результате задача становится нерешаемой даже теоретически.
>Даже при наличии такого требования задача реализуется не то, чтобы теоретически, но и практически - например, отключением проверки уникальности поля на время выполнения запроса.
Проверку уникальности можно вообще не вводить. Поле неключевое.
Вы уж выберите что-нибудь одно. | |
|
|
|
|
|
|
|
для: Trianon
(10.05.2009 в 12:02)
| | >А еще он не может быть нулевым, нецелочисленным, неопределеленным
Конечно. Мы ведь фактически имеем дело с порядковым номером.
>не может выходить за множество номеров имеющихся строк.
И тем самым исключить возможность добавления новых элементов в таблицу ?
>В результате задача становится нерешаемой даже теоретически.
Даже при наличии такого требования задача реализуется не то, чтобы теоретически, но и практически - например, отключением проверки уникальности поля на время выполнения запроса. | |
|
|
|
|
|
|
|
для: Cyrax
(10.05.2009 в 11:58)
| | ага. А еще он не может быть нулевым, нецелочисленным, неопределеленным, да и вообще не может выходить за множество номеров имеющихся строк. Исходя из того же источника озарения.
В результате задача становится нерешаемой даже теоретически.
Вопрос закрыт. | |
|
|
|
|
|
|
|
для: Trianon
(10.05.2009 в 11:33)
| | 1. чем обусловлено требование неотрицательного номера позиции?
Исходя из предметной области задачи номер позиции не может быть отрицательным
2. чем обусловлено требование уникального индекса на поле номера позиции?
Исходя из предметной области задачи номера позиций не могут совпадать | |
|
|
|
|
|
|
|
для: Cyrax
(10.05.2009 в 09:28)
| | 1. чем обусловлено требование неотрицательного номера позиции?
2. чем обусловлено требование уникального индекса на поле номера позиции? | |
|
|
|
|
|
|
|
для: Trianon
(10.05.2009 в 09:10)
| | ни тот ни другой фактор сортировать таблицу не мешают.
Тем не менее, вариант реализации задачи при наличии обоих факторов пока не представлен...
А заключение в транзакцию не решит вопрос с неотрицательностью. | |
|
|
|
|
|
|
|
для: Cyrax
(10.05.2009 в 08:59)
| | ни тот ни другой фактор сортировать таблицу не мешают.
Не говоря уже о том, что противник внутренней инконсистентности вроде Вас, заключит эти операторы в транзакцию. | |
|
|
|
|
|
|
|
для: Trianon
(10.05.2009 в 08:51)
| | Да, но только pos в таких случаях не только уникален, но ещё и неотрицателен.
А неортицательность необходима по той же причине, что и уникальность. | |
|
|
|
|
|
|
|
для: Cyrax
(10.05.2009 в 08:26)
| |
UPDATE tbl SET pos = pos - ($pos1 + $pos2 ) WHERE pos IN ( $pos1, $pos2);
UPDATE tbl SET pos = -pos WHERE pos IN ( -$pos1, -$pos2);
|
| |
|
|
|
|