Работа с записями

← →
Тыгыдым (2006-09-08 13:29) [0]

Вот, читаю понемногу форум...
Очень интересно...

У меня такой вопрос... Даже наверное два =)

1. Каким образом осуществлять работу при редактировании записей?
Есть Грид, кликаю дважды, открывается окно "Редактирование записи".
Здесь лучше использовать стандартные Edit, Memo и т.д. и заполнять их в OnShow, а потом постить?
Или можно использовать DBEdit, DBMemo, LookupCombo? Потому что для первого варианта для меня самый гемор заполнять ComboBox"ы, а потом искать, что же выбрал пользователь...

2. Работаю с Ораклом версии 9.2.1.0.
Есть справочник, в котором ключевое поле является строкой. Как лучше построить таблицу? Создать ключевое поле ID типа NUMBER, и поле KOD типа STRING? А можно создать ключевое поле типа Строка? Отразится ли это на быстродействии? Количество записей в этой таблице около 8-10 тысяч... Причем эта таблица практически не будет изменяться...

Спасибо.

← →
Desdechado © (2006-09-08 13:38) [1]

1. DB-компоненты как раз и предназначены для редактирования датасетов.
2. Все зависит от предметной области. Суррогатный ключи обычно эффекивнее, чем нативные. Ну, и числовые быстрее и индексы по ним тоже.

← →
Тыгыдым (2006-09-08 13:41) [2]

1. А не будет ли такой подход сказываться на производительности?
2. Что подразумевается под суррогатными и нативными ключами?
Насчет предметной области: это будет справочник МКБ (международный классификатор болезней). Например, запись: A00 - Холера (соответственно, код и название). Не очень хочется цеплять к этому еще и ID. 1С ведь использует в некоторых таблицах код типа Строка... Вот и хочу узнать насколько такой подход живуч?

← →
Desdechado © (2006-09-08 13:54) [3]

1. Каким образом?
2. Суррогатные - не принадлежащие предметной области, искусственные, удобные для внутреннего манипулирования. Нативные - из полей предметной области (например, номер паспорта с серией), но неудобны для манипулирования, разноформатны, часто из нескольких полей.
Не хочется цеплять, не цепляй. Если, конечно, классификатор стандартизован. Но я бы прицепил. Потому как часто оказывается, что уникальное по сути поле вдруг начинает иметь какие-то отклонения типа "вообще-то нет, но здесь исключение сделаем".

PS 1С - не догма и даже не пример для подражания.

← →
ANB © (2006-09-08 13:58) [4]

> PS 1С - не догма и даже не пример для подражания.

Я бы сказал - весьма вредный пример

← →
Тыгыдым (2006-09-08 13:58) [5]

Так... с (1) понятно.. Спасибо :)
Насчет (2)... Классификатор стандартизирован донельзя... Код A00 и прочие уникален и повторяться просто не может... Этот классификатор если и меняется, то раз в 5-10 лет (как болезнь новую найдут и придумают как назвать :))
Для примера, какой запрос будет быстрее работать (хотя бы в теории)?

SELECT kart.* FROM kart LEFT JOIN kartmkb ON kartmkb.kartid = kart.id LEFT JOIN mkb ON kartmkb.mkbid = mkb.id WHERE mkb.name = "A00"

или

SELECT kart.* FROM kart LEFT JOIN kartmkb ON kartmkb.kartid = kart.id WHERE kartmkb.id = "A00"

← →
Desdechado © (2006-09-08 14:02) [6]

соединение 3 таблиц всяко медленнее соединения 2 таблиц

← →
Тыгыдым (2006-09-08 14:04) [7]

Т.е. использование строкового ключа имеет смысл? =)

← →
Тыгыдым (2006-09-08 14:07) [8]

кстати а как будут работать запросы типа
LEFT JOIN ON <строковый код> = <строковый код>
относительно
LEFT JOIN ON <числовой код> = <числовой код>

← →
Наиль © (2006-09-08 14:07) [9]

Для связи таблиц всегда лучше использовать числовое поле (как правило, оно не видимо для пользователя). А строковый тип удобен для поиска информации. Например, если у кого-то такой код записан в истории болезней. Естественно, пользователь должен исметь возможность работать с этим кодом.

← →
Тыгыдым (2006-09-08 14:10) [10]

повторю (или уточню) вопрос:
какие могут быть подводные камни, если я буду использовать в качестве уникального кода тип String?

← →
Наиль © (2006-09-08 14:28) [11]

Представь себе, что у холеры появился синоним.
И его захотят добавить в базу. Как ты думаешь дадут синониму новый код или нет. Моё мнение таково - уникальный код не должен быть доступен пользователю. Работа с уникальным кодом привилегия программы. А от того строковый он или числовой зависит скорость. Лично я за невидимый пользователю дополнительный числовой код.

← →
Тыгыдым (2006-09-08 14:34) [12]

Я еще раз повторю:
код только уникальный. Если это так сомнительно, поищите в интернете справочник МКБ-10. Холер 10 штук (к примеру), но каждая из них отличается друг от друга... Но это все холеры. Поэтому их коды будут А00, А00.0, А00.1, А00.2 и т.д. Одинаковых быть не может СОВСЕМ.
Вот вопрос про скорость меня и гложет. Насколько медленнее будет работать система при использовании строки в коде? Какие проблемы могут вылезти (повторю, код уникальный 100% :))

> Насколько медленнее будет работать система при использовании
> строки в коде

Если 8-10 тысяч, то ты разницы не заметишь.

> повторю, код уникальный 100%

Если поле только для чтения.
А учитывая

> Есть Грид, кликаю дважды, открывается окно "Редактирование
> записи".

то есть риск.

← →
Тыгыдым (2006-09-08 14:59) [14]

Ну про Редактирование записи это другая тема немного.

Таблица МКБ будет иметь возможность модификации (а куда ж без нее?) но справочник уже несколько лет не меняется...
К тому же можно ведь сделать UNIQUE по этому полю, ведь так?

> [8] Тыгыдым (08.09.06 14:07)

В большинстве случаев (если не во всех) медленнее.

P.S. Ты бы хоть СУБД указал. А то в оракле, например, есть такой тип индекса как Bitmap Join Index, который позволил бы соединение 3-х таблиц превратить в соединение 2-х таблиц. Хотя, если отношение количества записей kartmkb к mkb невелико (не более 10), то Bitmap индексы вроде как неэффективны.

← →
Тыгыдым (2006-09-08 15:27) [16]

> В большинстве случаев (если не во всех) медленнее

Это я как раз понимаю. Вот насколько медленее??

> P.S. Ты бы хоть СУБД указал

[0] - Работаю с Ораклом версии 9.2.1.0.

Вот тоже вопрос. Каким образом лучше реализовать ограничения доступа? Внутри своей программы или с использованием ролей Оракла? Или комбинацией того и другого?

> Хотя, если отношение количества записей kartmkb к mkb
> невелико (не более 10)

kartmkb - связь между визитом пациента и болезнью. Максимум выявленных болезней за один визит это 5, в практике до трех, в основном 1 :)

> [16] Тыгыдым (08.09.06 15:27)
> Вот насколько медленее??

Согласись, глупый вопрос. Зависит от многих факторов.

> [0] - Работаю с Ораклом версии 9.2.1.0.

Действительно было. :)

> Каким образом лучше реализовать ограничения доступа?

Мое имхо, в СУБД это делать надо, т.к. существует масса инструментов прямого доступа помимо твоего приложения.

> kartmkb - связь между визитом пациента и болезнью.

Т.е. таблица будет довольно живо расти и уже за год, возможно, достигнет 1 млн. записей. Самих болезней в mkb ну может тыс. 10 будет. Тогда отношение уже около 100 выходит.
Знаешь, на первых порах можно и не заморачиваться с таким индексом. Вот когда начнет заметно тормозить селект, получишь примерно такое отношение или больше, тогда можешь попробовать добавить такой индекс. Посмотришь планы до и после индекса и решишь. Но мое имхо, лучше нормализовать эти таблицы и varchar ключ не использовать.

Работа с записями Найти похожие ветки