Форум: "Базы";
Текущий архив: 2002.09.12;
Скачать: [xml.tar.bz2];
ВнизАвтоинкрементные поля Найти похожие ветки
← →
MsGuns (2002-08-21 13:07) [0]Вот пришлось опять покопаться в чужой проге и, наконец, надоело.
Везде где только можно используются автоинкрементные поля, причем, как правило, еще и ключи. А я вот и не пойму чего-то, или я так глуп, что НИКОГДА не ипользую этот тип полей в своих разработках или одно из двух ? Кто мне по-дружески и убедительно разъяснит, на кой они нужны вообще, кроме, конечно, случаев, когда просто следует физически хранить записи в той последовательности, в которой они вводились юзером ? Хотя мне даже трудно представить на кой это может понадобиться, ведь порядок следования записей задается прежде всего смысловым наполнением некоторых их полей (дата, номер, код и тому подобное)
Особенно меня кумарит, когда автоинкремент используется как первичный ключ в нескольких связанных таблах, причем связки по совершенно другим полям.
Заранее благодарен всем, кто поделится
← →
Val (2002-08-21 13:28) [1]интересует поле типа автоинкремент парадокса или автоинкремент в принципе?
← →
Vovchik_A (2002-08-21 13:48) [2]Да как счетчик его юзают просто по всей видимости
← →
Val (2002-08-21 13:53) [3]>Vovchik_A (21.08.02 13:48)
по какой видимости? счетчик чего?
← →
OlegL (2002-08-21 14:14) [4]назначение единственное и неповторимое:
уникальное значение ключевого поля.
а если пр этом в связаных таблицах используются
другие поля - то это чухонство.
← →
Val (2002-08-21 14:22) [5]>OlegL (21.08.02 14:14)
..а если пр этом в связаных таблицах используются другие поля ..
не стоит делать таких однозначных выводов.
это совершенно нормально, есть такая штука как уникальный индекс, кроме первичного ключа. Кто вам мешает связывать таблицы по нему? а назначение PK, совершенно справедливо в сказли, состоит в однозначной идентификации записи в таблице бд. У вас он ничего кроме как уникальности записи может не означать, зачем тогда по нему вязать таблицы?
← →
Mike Kouzmine (2002-08-21 14:52) [6]По нему вязать опасно (в Парадоксе). При восстановлении базы после краха, могут быть кранты.
← →
MsGuns (2002-08-21 15:26) [7]Поясню вопрос. Мне неясно зачем выдумывать какие-то совершенно искусственные поля для уникализации ключей в таблицах, если ДОЛЖНО хватать (ессно, при нормально проработке реквизитного наполнения БД) естественных (информативных) полей ? А если надо что-то типа внутреннего порядкового номера записей, то пусть юзер сам и нумерует (простое поле типа целого). И никакой головной боли с "дырками" а автоикрементах. Иля я не прав ?
← →
Kuusiniemi (2002-08-21 15:31) [8]> MsGuns ©
О, батенька! Тема искусственных и естесственных ключей - эт такая тема, что всех нас переживет. :) И сторонник одной теории всегда готов порвать сторонника другой. :)
← →
MsGuns (2002-08-21 15:36) [9]>Kuusiniemi
>:) И сторонник одной теории всегда готов порвать сторонника другой. :)
Это что, ответ на вопрос ?
← →
Duce (2002-08-21 15:36) [10]Нет, не прав! Даже и аргументировать не буду, по этому поводу флейм в ФИДО бродил в околоСУБДэшных эхах около полугода...
Суррогатные ключи - абстрактное, но очень эффективное средство.
Представь себе связку customer - orders. И как ее программно вязать...
← →
Dimedrol (2002-08-21 15:40) [11]А я ОЧЕНЬ(!) люблю автоинкрементные поля
и сую их куда только можно ! 8-)
(в пределах разумного конечно)
Мне нравиться, что в моей таблице есть
поле по которому ВСЕГДА, В ЛЮБОЙ МОМЕНТ я могу однозначно
идентифицировать запись.
← →
MsGuns (2002-08-21 15:49) [12]>Duce
>Представь себе связку customer - orders. И как ее программно вязать...
Ну да, подумаешь, бином Ньютона ! ДАТА ЗАКАЗА + НОМЕР ЗАКАЗА (договора, документа и т.д.) - связующий ключ, причем априори УНИКАЛЬНЫЙ - для Orders, и НИКАКОЙ СВЯЗКИ, кроме лукапового, на Customer ! Все остальное - от лукавого ! Если очень хо иметь детализацию по клиенту, то заведи еще одну таблу, подчиненную Customer`у и держи там, например, список всех заказов для каждого покупателя. Хотя я не понимаю зачем, можно же поставить соотв.TQuery с параметрами на текущего клиента, тогда и детал никакой не нужен. Но причем тут суррогатные поля - не пойму...
← →
Val (2002-08-21 15:57) [13]>MsGuns © (21.08.02 15:26)
оговорюсь: тип автоинкремент парадокса славится своей неустойчивостью(его часто имитируют, заменяя на number и создавая собственный механизм вставки), поэтому следующее относится к общей теории:
представьте, в вашей таблице однозначно идентифицируют запись например 5 или даже более полей. Дабы не делать такой неповоротливый составной PK вы и создаете его из одного поля, что, несомненно, ускоряет доступ, но тогда ключ не несет никакой смысловой нагрузки.
← →
Mike Kouzmine (2002-08-21 15:59) [14]Возможноя ситуация: Уникальный номер -> ДАТА ЗАКАЗА + НОМЕР ЗАКАЗА. Дату присвоили, но номер пока нет (по разным причинам) или наоборот, но запостить запись надо, Тут спасает этот автоинкримент, который и дает уникадьность записи (ключа).
← →
Duce (2002-08-21 16:17) [15]Что-то не очень пойму вышеприведенный диалог. Чтобы повязать кустомера(запись о человеке) с его заказами, нужно в заказах хранить, например, номер паспорта - если естественные ключи. Номер паспорта - величина потенциально многосимвольная, ее нужно знать и т.п. Она лежит в двух таблицах, занимая вдвое больше места.
И взять суррогатный ключ - long int, 4byte. Обработка цифирей - куда как быстрее, хранение - куда как компактнее. Вот.
← →
MsGuns (2002-08-21 16:27) [16]>Duce
Вообще-то для этих целей используется кодирование, т.е. вместо ФИО или названия фирмы, которые очень длинные и в качестве ключей действительно тормозят да и память дисковую жрут безбожно, используется код (как правило не более 8 символов), куда сокращенно (аббревиатурно) записывается юзером что-то типа MSOFT вместо Microsoft Corporate
Сердито, но юзер быстро привыкает и ему это даже начинает нравится. Зато быстро и компактно.
← →
Desdechado (2002-08-21 17:02) [17]> сокращенно записывается юзером что-то типа MSOFT
тот же суррогатный ключ, только с попыткой смысловой нагрузки.
минусы:
1. строки медленнее чисел
2. наберет юзер MSОFT, а в ней О - русская или ноль. приехали :)
3. компактно? Integer 4 байта
← →
Duce (2002-08-21 17:32) [18]To Desdechado: мочи их в сортире! :))
ЗЫ: все беззлобно :)
← →
Anatoly Podgoretsky (2002-08-21 17:39) [19]Kuusiniemi © (21.08.02 15:31)
При том на куски и вроде здесь уже не далеки от этого.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2002.09.12;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.006 c