Тип поля, по которому осуществляется связь

← →
SelfDestructor (2002-02-26 18:16) [0]

Есть таблица, содержащая 2 поля: код (уникальное текстовое поле, 2 символа) и его описание
Есть другие таблицы, которые связаны с данной.
Вопрос: Нормально осуществлять связь по текстовому полю(оно же маленькое)? Или лучше завести в таблице целочисленный ID и связь осуществлять по нему? Что быстрее?

← →
deleon (2002-02-27 08:47) [1]

Быстрее тут не уместно, а вот нормально - уникальное целочисленное поле!

← →
DmitryV (2002-02-27 10:20) [2]

2deleon: Поясни, пожалуйста, почему "нормально" только целочисленное поле?

2SelfDestructor: по скорости, IMHO, без особой разницы, а вот по мощности ключа и объему хранимых данных - текстовое поле, наверное, лучше...

С уважением

← →
KSN (2002-02-28 15:29) [3]

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

← →
Fay (2002-03-01 05:07) [4]

2DmitryV
4 > 2 ?

← →
Dok_3D (2002-03-01 07:11) [5]

2Dmitry
а вот по мощности ключа и объему хранимых данных - текстовое поле, наверное, лучше...
Что-то не могу понять, в чем же текстовое поле мощнее ?

А вообще, абсолютно согласен с deleon. Нормально - уникальное целочисленное поле! Я бы еще добавил - автоинкрементное.
Навигация по целочисленным полям происходит быстрее.

← →
deleon (2002-03-01 08:55) [6]

К тому-же числовые поля избавлены от транслитерации типа Oem->Ansi, а так-же не затрачивается время на символьное декодирование (в зависимости от реализации СУБД). Для Paradox автоинкремент хорош, но есть недостатки: если случайно удалить master-запись, то восстановить ее практически невозможно с тем-же значением, поэтому предпочтительнее самому генерить уникальное значение в не read-only integer field.

← →
Anonim (2002-03-01 09:49) [7]

По-моему без разницы. Тем более, если уникальное поле является ключом, то зачем вводить еще один?

← →
СергейФ (2002-03-01 11:18) [8]

-> а вот по мощности ключа и объему хранимых данных - текстовое поле, наверное, лучше...
Что-то не могу понять, в чем же текстовое поле мощнее ?

а заложить кодировку "112.12.4576" где первый ряд цифр берёт код (ID) первой таблицы, второй код (ID) другой таблицы и т.д.

по такому полю можно построить дерево
можно искать по вложенности веток и т.д.

Ваше численное поле может может такое сделать?

← →
Dok_3D (2002-03-01 11:37) [9]

2СергейФ
>> а заложить кодировку "112.12.4576" где первый ряд цифр берёт >> код (ID) первой таблицы, второй код (ID) другой таблицы и т.д.

Ну ты даешь !!!!!
Это же как такое в голову прийти-то могло ? Ты вообще о ссылочной целостности слышал когда-нибудь ?
Просто нет слов.
Во всех нормальных БД для ссылок на другую таблицу используют отдельное поле для каждой таблицы. Внешний ключ называется.

А время твоих "112.12.4576" уже безвозвратно уходит. Годится только для написания IP-адреса. :))))

← →
deleon (2002-03-01 14:17) [10]

Дерево отлично строится с участием в таблице всего двух целочисленных полей типа ID и LINK и ограничения на количестве ветвей, как в вышеприведенном примере не будет!

← →
СергейФ (2002-03-01 15:17) [11]

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

И неосвоенный мною способ построения дерева с участием двух целочисленных полей типа ID и LINK для такой мальнькой задачи казался сложнее.

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

Тип поля, по которому осуществляется связь Найти похожие ветки