Какой тип данных использовать для порядкового номера?

Question

Всякий раз, когда у меня есть записи / объекты, которые я хочу разместить в определенном порядке, я обычно создаю поле с именем Ordinal.

Я часто задаюсь вопросом, будет ли лучше использовать целое или десятичное значение для порядкового поля.

Это соображение при перемещении объекта в другую позицию в порядке:

• Если вы используете последовательные целые числа, вам нужно будет серьезно переработать все ординалы (или, по крайней мере, ординалы, которые попадают до исходной позиции перемещаемого объекта).

• Если вы используете целые числа, но распределяете их (возможно, с интервалом в 1000), то вы можете просто изменить порядковый номер на значение средней точки между окружающими объектами, куда вы хотите переместить объект. Это может не сработать, если где-нибудь внизу строки вы получите последовательные целые числа.

• Если вы используете десятичные числа, вы можете просто найти среднее значение ординалов окружающего объекта и использовать его для перемещения объекта.

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

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

Answer 1

Десятичные дроби, кажется, решают вашу проблему довольно хорошо. Поскольку десятичные числа - это просто число с плавающей запятой 10, на самом деле у вас есть много доступных цифр. Если вы не видели случаев, когда у вас было достаточно много цифр, и у вас была причина подозревать причину необходимости неограниченного числа цифр, я бы позволил этому прокатиться.

Если вам действительно нужна альтернатива и вы не видите необходимости придерживаться базовых данных, вы можете использовать арифметику тумблера . Основная идея заключается в том, что это обозначение места, которое можно бесконечно расширять в каждой позиции. Довольно просто концептуально.

Answer 2

"Это может не сработать, если где-нибудь внизу строки вы получите последовательные целые числа."

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

Answer 3

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

Answer 4

«Определенный порядок» основан на данных за пределами таблицы? Если так, почему бы не включить его, чтобы вы могли выполнять сортировку динамически? Если оно уже есть в таблице, добавление поля является излишним.

Answer 5

Раньше я использовал десятичный тип для поля такого типа, чтобы упорядочить записи в таблице, которую мы фактически выставили клиенту, чтобы он мог установить свой собственный заказ. Хотя это звучит глупо, нашим клиентам это понравилось; они нашли это очень интуитивным. Они очень быстро поняли, что могут использовать числа, например 21,5, для перемещения между 21 и 22.

Может быть, это потому, что они были бухгалтерами.

Answer 6

Я помню, что этот вопрос был похож на предыдущий пост. Его можно найти здесь:

Порядок приоритетов SQL Server

Связанный список все еще будет работать, но это гораздо более простое решение, если вы не хотите отслеживать отношения родитель-потомок.

Похоже, что вы хотите, это связанный список. Таким образом, вы всегда знаете, что будет дальше, и вам не нужно будет угадывать. Таким образом, поле позиции будет указателем на объект, следующий за ним.

Проблема, с которой я всегда сталкивался при использовании произвольных чисел для позиции, заключается в том, что она может быстро упасть до энтропии. Что, если будет добавлено больше элементов, число станет последовательным и т. Д. И т. Д. Это может быстро стать неуправляемым, если список элементов изменит положение.

Чтобы реализовать это в таблице сервера SQL, добавьте еще одно поле с тем же типом данных, что и первичный ключ. Если поле пустое, то это нижний элемент в списке. Если вы храните несколько списков в одной и той же таблице, вы, вероятно, захотите добавить еще одно поле с именем ListID, в котором все строки с одинаковым ListID принадлежат одному списку. Так что-то вроде этого.

Table:
ID INT
ListID INT
Child INT

Pararent Row For first list:
 1, 1, 2
First Child
 2, 1, 3
Second Child
3, 1, NULL

Parent Row for second list:
4, 2, 5
First Child
5, 2, 6
Second Child
6, 2, NULL

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