простые вопросы по Ораклу

[Sabina]

1) Какой тип данных лучше выбрать для поля, где юзер может печатать текст длинною в несколько строк? Хотелось бы обойти без BLOB-ов, если возможно. Какое ограничение на кол-во chars в самом длинном до BLOB-а типе?

2) Есть таблица где хранятся административные данные по запросу (номер, даты, кто исполняет и т.д.) и есть таблица, где собраны поля описаний для этого запроса (типа short description, detailed procedure description, QAPlan, backoutPlan, problems), ну скажем 6 полей varchar(255).
Имеет ли смысл все эти описательные поля совать в одну таблицу или лучше сделать отдельно таблицы для каждого поля? Если наличие их всех в одной таблице влияет на производительность, при каком примерно количестве записей это начинает ощущаться?

Спасибо,
Сабина

[zVlad]

.........

2) Есть таблица где хранятся административные данные по запросу (номер, даты, кто исполняет и т.д.) и есть таблица, где собраны поля описаний для этого запроса (типа short description, detailed procedure description, QAPlan, backoutPlan, problems), ну скажем 6 полей varchar(255).
Имеет ли смысл все эти описательные поля совать в одну таблицу или лучше сделать отдельно таблицы для каждого поля? Если наличие их всех в одной таблице влияет на производительность, при каком примерно количестве записей это начинает ощущаться?

Спасибо,
Сабина

Я бы построил вторую таблицу из столбцов: Номер запроса (внешний ключ к первой таблице и поисковый индех), Short description, Detailed procedure description, QAPlan, BackoutPlan.

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

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

[Sabina]

Я бы построил вторую таблицу из столбцов: Номер запроса (внешний ключ к первой таблице и поисковый индех), Short description, Detailed procedure description, QAPlan, BackoutPlan.

Спасибо. Мне очень нравится подход когда на стадии дизайна можно думать только о дизайне

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

Нет, там у них one-to-one, просто description field с описанием с какими проблемами (возможно!) пришлось столкнуться во время имплементации. То есть выделять отдельные проблемы не нужно.

Лучше сначала сделать правильную модель данных, и лишь потом проводить анализ производительности для уже существующей модели.

А этот анализ производительности может в свою очередь привести к изменению модели?

И все-таки с datatypes...
Получается максимально, что я могу определить избегая CLOB - это varchar2(n).
Согласно этому сайт, предел для этого типа 4000 bytes=2000 chars. В принципе это выше крыши даже для детальных описаний в этой системе.
LONG как я поняла deprecated in Oracle 9. Нашла упоминание LONG VARCHAR на других сайтах, но я так поняла, что это какой-то производный тип возможно и от того же LONG, потому что на данном сайте он не упоминается.

Меня напугали CLOB-ами в том плане, что потом гораздо сложнее программировать.

Сабина.

[zVlad]

.......

Лучше сначала сделать правильную модель данных, и лишь потом проводить анализ производительности для уже существующей модели.

А этот анализ производительности может в свою очередь привести к изменению модели?

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

И все-таки с datatypes...
Получается максимально, что я могу определить избегая CLOB - это varchar2(n).
Согласно этому сайт, предел для этого типа 4000 bytes=2000 chars. В принципе это выше крыши даже для детальных описаний в этой системе.
LONG как я поняла deprecated in Oracle 9. Нашла упоминание LONG VARCHAR на других сайтах, но я так поняла, что это какой-то производный тип возможно и от того же LONG, потому что на данном сайте он не упоминается.

Меня напугали CLOB-ами в том плане, что потом гораздо сложнее программировать.

Сабина.

[/quote]

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

Прочитал написанное и подумал - типичный ответ "системщика". Анекдот есть на эту тему. Холмс и Ватсон летят на воздушном шаре в тумане, давайте, говорит Ватсон, спустимся и спросим кого-нибудь где мы находимся. Спустились, видят мужик стоит, спросили, тот отвечает - на воздушном шаре. Поднялись, Холмс спрашивает ты, мол Ватсон понял кто был тот мужик. Нет. Системщик. Почему. Он нас внимательно выслушал и дал правильный, но совершенно бесполезный для нас ответ.

[JustMax]

1) Какой тип данных лучше выбрать для поля, где юзер может печатать текст длинною в несколько строк? Хотелось бы обойти без BLOB-ов, если возможно. Какое ограничение на кол-во chars в самом длинном до BLOB-а типе?

Тип VARCHAR2 4000 байт/символов - если используется ASCII или ISO-8859-1/15 кодировки. Если используется UNICODE или спец. кодировки (китайская, японская) соответственно в 2-3-4 раза меньше

2) Есть таблица где хранятся административные данные по запросу (номер, даты, кто исполняет и т.д.) и есть таблица, где собраны поля описаний для этого запроса (типа short description, detailed procedure description, QAPlan, backoutPlan, problems), ну скажем 6 полей varchar(255).
Имеет ли смысл все эти описательные поля совать в одну таблицу или лучше сделать отдельно таблицы для каждого поля? Если наличие их всех в одной таблице влияет на производительность, при каком примерно количестве записей это начинает ощущаться?

Спасибо,
Сабина

ИМХО все поля зависящие от одного PK должны быть в одной таблице! Небольшой совет - в начале таблицы описывайте поля которые, скорее всего, будут заполнены, а в конце которые чаще всего будут пустые. Сэкономите много места

[Lazy44]

1) Varchar2(4000). CLOB если только надо ввести больше чем 4000 байт.

2) Если отношение между таблицами один к одному, я бы посоветовал хранить все в одной таблице. Нет смысла раскидывать по разным таблицам поля по 255 байт. Мой опыт говорит мне, что производительность начинает страдать, если размер поля превышает параметер db_file_multiblock_read_count*db_block_size. Для OLTP систем это означает более чем одно чтение. Но я бы сказал, что это ухудшение очень теоретическое и очень маленькое, конечные юзеры его не замечали. Если у вас действительно большие данные (больше чем 4000 байт одно поле), то сделайте их CLOB, и при создании таблицы поместите CLOB в другой tablespace.

От количества записей производительность зависит только если optimizer делает full table scan.

[Sabina]

Прочитал написанное и подумал - типичный ответ "системщика".

Тем более здорово, когда системщик считает, что сначала грамотный дизайн, а потом производительность

Сабина

[Sabina]

Тип VARCHAR2 4000 байт/символов - ...

Все дошло. В упомянутых вами кодировках char - 8 bit, в юникоде - 16, в китайских и проч. и того более.

ИМХО все поля зависящие от одного PK должны быть в одной таблице! Небольшой совет - в начале таблицы описывайте поля которые, скорее всего, будут заполнены, а в конце которые чаще всего будут пустые. Сэкономите много места

В моей базе, если засунуть все относящееся к request в одну таблицу, то получится пол базы в одной таблице Вот я и решила описательные поля занести в отдельную таблицу.

Также выделила comments, поскольку там one-to-many , да и в документацию по request они собственно не входят, они просто влияют на request corrections/backout/denial. И вызываются совсем из другого UI-я, являются user specific, в общем так кажется удобнее.

Вот собственно драфт схемы. Ключей пока на вторую половину не поставила, поскольку еще thinking process идет полным ходом.

Всем еще раз спасибо за советы. Вот уж не ожидала такой активности в воскресение. Думала я одна такая бедолага у компа сижу. А у нас уже лето целую неделю. Днем жара до 25-30 С.

Сабина

[zVlad]

Прочитал написанное и подумал - типичный ответ "системщика".

Тем более здорово, когда системщик считает, что сначала грамотный дизайн, а потом производительность

Сабина

Тут во мне не только системщик (кстати бывший), но и прикладник (тоже бывший) говорит. Столько за жизнь уже налипло, однако
Вспоминается заставка системы Примус (если кто знает), кажется из Шнитке:

" И он уже не тот что был когда-то
Чужие судьбы став его судьбой
Влекут и манят за собой"

Или что в этом роде. Или не из Шнитке, но точно это было в Примусе.

[Sabina]

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

Классный совет! А я их все больше по смыслу пыталась организовать

Сабина

[Sabina]

Вспоминается заставка системы Примус (если кто знает)

Это не та, что была на EC-ке?

Сабина

[zVlad]

.......

ИМХО все поля зависящие от одного PK должны быть в одной таблице! Небольшой совет - в начале таблицы описывайте поля которые, скорее всего, будут заполнены, а в конце которые чаще всего будут пустые. Сэкономите много места

В моей базе, если засунуть все относящееся к request в одну таблицу, то получится пол базы в одной таблице Вот я и решила описательные поля занести в отдельную таблицу.

...которую в большинстве случаев будете соединять с первой. Хотя это не так уж и страшно. В общем я согласен с JustMax в этом плане.

Также выделила comments, поскольку там one-to-many , да и в документацию по request они собственно не входят, они просто влияют на request corrections/backout/denial. И вызываются совсем из другого UI-я, являются user specific, в общем так кажется удобнее.

Вот собственно драфт схемы. Ключей пока на вторую половину не поставила, поскольку еще thinking process идет полным ходом.

Всем еще раз спасибо за советы. Вот уж не ожидала такой активности в воскресение. Думала я одна такая бедолага у компа сижу. А у нас уже лето целую неделю. Днем жара до 25-30 С.

Сабина

Посмотрел Вашу модель, не вдаваясь в детали заметил approver1, approver2, .... - очень не красивое и неправильное решение. А если понадобится пятый?, а где будете хранить информацию типа как в итоге отреагировал Approver? Это нарушение правила рарешения многие-к-одному. Должна быть создана таблица для многих.

[zVlad]

Вспоминается заставка системы Примус (если кто знает)

Это не та, что была на EC-ке?

Сабина

Она самая. В то время как на западе было одно лишь TSO, наши умельцы наделали разные Primus, OKO, Jack, Jessy и т.д.

[Sabina]

Посмотрел Вашу модель, не вдаваясь в детали заметил approver1, approver2, .... - очень не красивое и неправильное решение. А если понадобится пятый?, а где будете хранить информацию типа как в итоге отреагировал Approver? Это нарушение правила рарешения многие-к-одному. Должна быть создана таблица для многих.

Я знаю. И тоже до хрипоты спорила с юзерами, что так не надо. Но они упираются до последнего, что у них 4 апрувала и точка. Это-де кровью записано в ChangeManagement procedure. Впрочем вы правы, сделаю-ка я one-to-many и по поводу approvers. Там у них 3 отдела и над ними сидит один директор. То есть директор + 3 менеджера - approval commitee для всех запросов. Иногда если кто-то из них отсутствуют, они могут назначать proxy для approval и proxy не обязательно является юзером системы
Ну и еще для особо срочных requests достачтоно 2 approval-а, а не все 4.

Поправила схему вот так. Получилось даже лучше, потому что теперь и proxy и comments можно просто в эту таблицу Approvals засадить.

Сабина

[Sabina]

Она самая. В то время как на западе было одно лишь TSO, наши умельцы наделали разные Primus, OKO, Jack, Jessy и т.д.

работала я на этом чуде
До сих пор не понимаю, как можно было мириться с тем, что EC-1066 висела почти каждый день по 6 часов

А вот еще прикол от нашего бывшего системщика. У них в одном из сибирских ВЦ не хватало мониторов. Так вот на print server, по самому верху клавиатуры было крупными буквами написано "После двух пик-пик нажмите клавишу enter."

Сабина