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

[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."

Сабина

[zVlad]

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

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

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

Сабина

Так это у Вас не учебный проект Так ведь уже такие системы давно существуют. Remedy Со., например, продукт. А юзеров надо держать подальше от того, что является предметом вашей ответственности. Эти же юзеры, с наглой рожей придут и скажут, а нам мол нужен теперь пятый или что-нибудь еще в этом роде.

[zVlad]

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

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

...

Если мирились значит можно было. Я лично видел много случаев когда ЕС работали очень даже надежно. Например, на ЖД-ых ВЦ пятьнадцать (как помнится) минут простоя считалось ЧП и делался доклад начальнику дороги. А начальник, как я понимаю, автоматом бы подписывал приказ об увольнении начальника ВЦ. Что-то я не помню чтобы там хоть раз начальника ВЦ уволили. Хотя конечно и случаев ужасной работы ЕС-ок было немало.

[Lazy44]

... но точно это было в Примусе.

Рильке

[Sabina]

Так это у Вас не учебный проект Так ведь уже такие системы давно существуют. Remedy Со., например, продукт. А юзеров надо держать подальше от того, что является предметом вашей ответственности. Эти же юзеры, с наглой рожей придут и скажут, а нам мол нужен теперь пятый или что-нибудь еще в этом роде.

Учебный, но делаю я его под конкретную заинтересованную сторону. То есть моя выгода такая: если сделаю что толковое, то а) сама научусь, б) если им понравится, то может на работу возьмут.
Про Ремеди знаю, даже работала там. Они хотят 30 штук с этой конкретной фирмы, и их жаба душит. Для них это большой expense, а change management уже хочется автоматизировать.
Я даже нашла open source Zentrack (php) и им показала, но они говорят, если я сделаю именно под их workflow и JSP, то они лучше подождут мое.

Сабина

[JustMax]

Честно говоря, у меня получается в два раза меньше таблиц user, request, department, approvals . Все! usertype, userstatus, requestpriority под вопросом, а именно : если только значения в них НЕ являются статическими т.е. заранее не известны или очень volаtile. Иначе обходимся check constraint с перечислением значений. Еще совет - дабы автоматизировать approved бизнес правило, можно на таблицу approvals навесить table level триггер, где проверять количество аппрувалов и, если их количество достигает заданного, менять в таблице request approved статус на true. Я уже говорил: не плодите сущности без надобности!
IMHO!

[zVlad]

Так это у Вас не учебный проект Так ведь уже такие системы давно существуют. Remedy Со., например, продукт. А юзеров надо держать подальше от того, что является предметом вашей ответственности. Эти же юзеры, с наглой рожей придут и скажут, а нам мол нужен теперь пятый или что-нибудь еще в этом роде.

Учебный, но делаю я его под конкретную заинтересованную сторону. То есть моя выгода такая: если сделаю что толковое, то а) сама научусь, б) если им понравится, то может на работу возьмут.
Про Ремеди знаю, даже работала там. Они хотят 30 штук с этой конкретной фирмы, и их жаба душит. Для них это большой expense, а change management уже хочется автоматизировать.
Я даже нашла open source Zentrack (php) и им показала, но они говорят, если я сделаю именно под их workflow и JSP, то они лучше подождут мое.

Сабина

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

Неужели та контора, Сабина, не понимает что того что предлагает Ремеди за 30 штук, получить за меньше просто не возможно. За меньше можно получить что-нибудь более (и очень даже) простое. А самое главное, кто будет сопровождать после успешного вредрения? Только Вы, Сабина, им об этом не говорите. В Ваших интересах, чтобы они и дальше заблуждались, и в конце концов купили Ремеди, а Вас бы наняли за этим Ремеди присматривать.

[Sabina]

Честно говоря, у меня получается в два раза меньше таблиц user, request, department, approvals . Все! usertype, userstatus, requestpriority под вопросом, а именно : если только значения в них НЕ являются статическими т.е. заранее не известны или очень volаtile. Иначе обходимся check constraint с перечислением значений. Еще совет - дабы автоматизировать approved бизнес правило, можно на таблицу approvals навесить table level триггер, где проверять количество аппрувалов и, если их количество достигает заданного, менять в таблице request approved статус на true. Я уже говорил: не плодите сущности без надобности!
IMHO!

status, type, department. etc. выделены в отдельные таблицы, потому что как вы справедливо заметили, могут в любой день добавить департмент или разбить одни на два. То же со стастусом юзера, пока очень простенько, но возможно придется поменять/добавить.

триггер на таблицу как средство отслеживания статуса не пойдет, там очень много у них этих статусов, вообще сам workflow очень сложный. Если один из approver-ов делает correctioins ли в принципе возражает, это все идет обратно к submitter, или там QA недоволен. Короче делалось с учетом всех этих прибамбасов.

Сабина

[Sabina]

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

По этому поводу вот что могу сказать... Одно из их преимуществ - это все интегрированно (help desk, change management, remedy web...).

Когда эта фирма проводила research - Remedy's Change Management оказался одним из наиболее близких к их Workflow алгоритмов. Я думаю Remedy достаточно оптимальна для крупных фирм, там среди заказчиков и Boeing, Walmart, Lockheed Martin, Livermore Lab ....
Для них 30 штук - нормальный расход. Мелким же компаниям это невыгодно.

Сам по себе продукт мне не очень нравился когда я там работала. Даже в самой старой ARS и то баг выскакивал то тут то там. А уж сколько от заказчиков наслушалась. Но факт налицо - берут их продукт.
У меня и сейчас там трое знакомых работает ( они теперь BMC company) и по их словам дела в фирме идут очень хорошо. Правда продукт они поругивают, по крайней мере тот из знакомых, что в tech support сидит.

Неужели та контора, Сабина, не понимает что того что предлагает Ремеди за 30 штук, получить за меньше просто не возможно. За меньше можно получить что-нибудь более (и очень даже) простое. А самое главное, кто будет сопровождать после успешного вредрения? Только Вы, Сабина, им об этом не говорите. В Ваших интересах, чтобы они и дальше заблуждались, и в конце концов купили Ремеди, а Вас бы наняли за этим Ремеди присматривать.

Они не будут покупать Ремеди однозначно. И сопровождать некому и в бюджет не влазит, и пока они ведут Change Management на бумаге и никто от этого не умер. И самое главное сопровождать Remedy - это последнее, чем я хотела бы заниматься. У меня к ним личные счеты. Меня оттуда вынудили уйти потому что я срочно уехала на 3 недели в Россию к папе, который перенес инфаркт. Сначала сказали ОК - езжай. А потом в самый день перед вылетом, вызывает меня к себе менеджерша и предупреждает, что у меня всего 2 недели отпуска. А у меня уже билеты куплены и т.д. А вопрос был поставлен четко: или я сама ухожу или они меня по приезду обратно увольняют. Я конечно сама ушла, тем более что натерпелась я там немало и уже к тому моменту сама хтела уходить. Но дело было не в компании, а в team lead. Она меня просто органически возненавидела с первого дня. И поэтому несмотря на excellent performance и customer awards, меня оттуда вот таким вот образом поперли (менеджерша с team lead все время ходили парой). Сорри за личное в таком разделе, но вот накатило...

Насчет сопровождения, это тоже недешевое удовольствие. Эта маленькая фирма нашла мужика, который вызвался поставить Help Desk за 35 в час, но он плохо знал Юникс и в итоге ничего на их конфигурацию посадить не смог.
Потом они нашли ребят из Ремеди (моих знакомых) за двойную стоимость, которых им пришлось долго уламывать, ибо те по контракту не имеют право работать на стороне.
В общем не дозрели они поиметь такой же тройной геморрой еще и с Change Management.

Сабина

[Sabina]

.... Еще совет - дабы автоматизировать approved бизнес правило, можно на таблицу approvals навесить table level триггер, где проверять количество аппрувалов и, если их количество достигает заданного, менять в таблице request approved статус на true.

Кстати триггеры будут на тот же статус и будут email notifications во все стороны после смены статуса. Но полностью переложить смену статуса на триггер невозможно. Скажем первый approver сделал поправки, тогда все это идет rolled back to submitter, если он не сделал поправку- сопоставляется с тем что сказали остальные три. Потом QA может развернуть. Такое нерационально все на триггеры возлагать (ИМХО!).

Сабина

[JustMax]

.... Еще совет - дабы автоматизировать approved бизнес правило, можно на таблицу approvals навесить table level триггер, где проверять количество аппрувалов и, если их количество достигает заданного, менять в таблице request approved статус на true.

Кстати триггеры будут на тот же статус и будут email notifications во все стороны после смены статуса. Но полностью переложить смену статуса на триггер невозможно. Скажем первый approver сделал поправки, тогда все это идет rolled back to submitter, если он не сделал поправку- сопоставляется с тем что сказали остальные три. Потом QA может развернуть. Такое нерационально все на триггеры возлагать (ИМХО!).

Сабина

Отчего ж . На триггеры прекрасно все ложится. Строится конечный автомат. Состояния, значения полей (must be, may be, must not be) , возможные переходы между состояниями при update, insert, delete накладывается на матрицу (отдельная таблица) и вуаля. В триггере ноль бизнес логики - он только накладывает изменения данных на матрицу и выполняет откат если состояние запрещено или возможный вызов процедур если таковые для данного события/перехода/состояния определены в матрице. При особенно сложной логике приложений только так и спасаемся. Пример - кредитный договор в банковской системе со всеми сложными состояниями присущими таким обьектам. Прикажете мне все в клиенте проверять (win, bean, web, appserver whatever) ? Мое глубокое IMHO - зная и используя возможности развитых баз данных хотя бы на 20-30% (не для написания business logic а только для поддержания business integrity) можно избежать написания тонны "бизнес логики" на любом клиенте.