информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / sysadmin
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
не такой простой вопрос о простых базах 02.11.03 12:01  Число просмотров: 1008
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Вопрос конечно интересный и проблема понятна в "принципе".
> Можете мне поверить, гораздо хуже, когда разные данные в
> находятся в одном "справочнике".

Думаю, Вы правы. Хотя об одной таблице речь не идёт. Я пропостил ответ, "в корень" ветки. Посмотрите, плз.
<sysadmin>
Простой вопрос о простых базах 01.11.03 04:30   [whiletrue]
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
В той конторе, где я работаю, часть баз данных – «навязана сверху». Мы не имеем права что-либо менять в их структуре. Вернее в «отчётных форматах». Вопрос о том, что можно посоветовать разработчикам «локализованных» версий, что бы избавиться от хм. гм-гм (см. ниже) ?

Одна из особенностей тех баз в том, что практически все «справочники» представляют отдельные таблицы. На каждую сущность – своя таблица. Например, территориальные районы – отдельная таблица, города – другая таблица, и т.д. Таким образом, в базе присутствует порядка 90-100 различных «справочных» таблиц (число варьирует от релиза к релизу).
Практически все таблицы имеют одинаковую структуру типа, id, textval, code1, code2.
Заполнение – мизерное 10-100 записей на таблицу. Интенсивность изменений – почти нулевая. Очень редко оператор добавляет новые данные в справочники.

Что думают отцы-архитекторы?
Уточнения 04.11.03 01:31  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Ещё раз спасибо за реакцию. Даже не ожидал. Лично для меня все мнения важны и интересны.

Вот несколько уточнений ко всем новым постингам. Извините, что отвечаю в корень, плз.

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

2) Теоретически "группировка" не представляет труда. Выше были и мои соображения, да и "вайл-тру" с ручника забыл сняться ;))) -
достаточно ввести дополнительное поле для кодирования самой сущности.

3) Думаю, что всё же правы те, кто отклинулся первыми на мой пост, и кто сказал, что не стоит группировать данные из отдельных справочных таблиц. В случае "группировки", на мой взгляд, происходит некоторое смещение акцентов на логику-клиента (даже в простейших операциях придётся включать дополнительный код в сиквел-запросах в клиентской проге). Если это решать на уровне представления данных на сервере, например при помощи создания просмотров (view), то зачем "группировать" в 20 таблиц, чтобы потом возвратиться к 100 view?

4) То, что я постил относительно оптимизации при группировке - в реальной ситуации может оказаться иллюзией. Один неплохой буржуй (насколько буржуи вообще могут быть неплохими) мне подсказал, что в случае группировки увеличивается вероятность "lock" справочных таблиц, если это реализовано на мелкомягком сиквеле. Конечно, не следует это принимать за чистую монету, т.к. очень много зависит от того, как построен клиент.

5) Ситуация интересна, конечно, чисто теоретически. Как следует организовывать "справочную инфу" в DBMS при большом числе справочных сущностей (не записей, а самих таблиц). Один гиганский буржуйский умище пропостил (в другом форуме), что, дескать, бывают базы и числом таблиц 1640. Ну бывают, так бывают. Нам до них (до буржуев) далеко.

ПС. Ещё раз спасибо всем. И может закроем?
Re: Уточнения 04.11.03 14:31  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
Нормализация - это конечно хорошо... Но иногда есть однотипные справочные данные, которые удобнее хранить в одной таблице и при этом не будет нарушение какой-либо формы нормализации, а всего-навсего будет иное, более удобное представление данных.

Пример.
Старый вариант: Имеем две таблицы - Город и Улица. Пояснять их структуру я думаю не обязательно.

Новый вариант: Имеем две таблицы - Area (некоторая абстракция) и Area_type.

Структура таблицы Area:
Area_id
Node_id (pointer to node Area_id)
Area_type_id
Area_name
-----
Primary key Area_id
Unique key Node_id, Area_type_id, Area_name (clustered)
etc.

Структура таблицы Area_type
Area_type_id
Area_type_name
-----
Primary key Area_type_id (clustered)

---------------------------------------
В случае добавления новых унификаторов как район или регион, в 'старом варианте' пришлось бы создавать новые таблицы, корректировать внешние ключи таблиц старых таблиц и перелопачивать все представления, основанные на этих справочных данных.
В 'новом варианте' достаточно добавить новую запись в таблицу 'Area_type' и всего навсего перепривязать данные к нодам. Указанный кластерный индекс должен обеспечить быстрый доступ и хранение данных для движка SQL сервера.
Твоя тема, хочешь - закрывай :) 04.11.03 13:54  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> 4) То, что я постил относительно оптимизации при
> группировке - в реальной ситуации может оказаться иллюзией.
> Один неплохой буржуй (насколько буржуи вообще могут быть
> неплохими) мне подсказал, что в случае группировки
> увеличивается вероятность "lock" справочных таблиц, если
> это реализовано на мелкомягком сиквеле. Конечно, не следует
> это принимать за чистую монету, т.к. очень много зависит от
> того, как построен клиент.
Тем не менее до какой-то степени это справедливо, за одним маленьким "но": подавляющее большинство локов на справочных таблицах будут локами чтения, а их количество при ничтожно малом числе локов записи на производительность в широком диапазоне значений вообще не влияет.
Твоя тема, хочешь - закрывай :) 05.11.03 00:49  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Тем не менее до какой-то степени это справедливо, за одним
> маленьким "но": подавляющее большинство локов на справочных
> таблицах будут локами чтения, а их количество при ничтожно
> малом числе локов записи на производительность в широком
> диапазоне значений вообще не влияет.

Да, конечно, ты прав.
Ответ всем сразу 02.11.03 04:47  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
Отвечаю в корень всем сразу.

1) Спасибо, что обратили внимание.

2) Мне немного неудобно перед всеми за то, что задал вообщем-то дурацковатый вопрос.
Особенно неудобно перед «Лёшкой». Речь не идёт о локализации в нормальном для IT смысле этого слова. Ещё раз мои извинения, братцы.

Я подумал, что может «переписать» эту базу для нашей конторы. Сохранив при этом близкие сердцу министерцев обменные форматы данных.
Они (министерцы) говорят так: «Локально у себя (т.е. у нас) - вы можете использовать любое представление данных. Делайте, как хотите, если структура нашей базы (т.е. министерской) вас не устраивает. Вы (т.е. мы) обязаны сохранить совместимость на уровне выходных обменных форматов данных».
При этом под выходными обменными форматами они понимают целиком базу данных, упакованную в аксесовский файлик. Обмен весьма примитивен. По существу мы передаём в Москву не обновления – а целиком всю базу. Это их требование.

3) О том, на чём написано.
Министерцы написали всё в MS Access. Вернее они наняли проектировщиков из двух регионов России. Думаю, помыты не плохие бабки (упс., извините, товарищ майор, молчу). Нам отдали «as is» в аксесе. Сказали – юзайте (а мы - сказали ешь, значит ешь; сказали б не ешь- значит не ешь).

4) О том, зачем переписывать.

4.1) В сетевой многопользовательской среде – юзать это невозможно. Оно – не работает.
С некоторыми усилиями мы передвинули наш «локализованный» вариант базы на мелкомягкий сиквел. По крайней мере, наша публика в конторе теперь хоть работать может (сетевая обработка)

4.2) Клиентское ПО (язык не поворачивается его таковым называть) – оставили прежним – Access. Оно хм., гм.-гм.
Вот я и подумал – ежели уж переделывать, то надо б переделывать всё - и базу, и клиентскую прогу. Времени уйдет, думаю, месяца три, если писАть самому (не так уж и много).

5) О том, как можно было б переписать + мои пяти-копеешные около-аргументишки.

Можно было б "сгруппировать" справочные сущности, объединив их в несколько таблиц. А не 100 как сейчас.
Для различения последних (когда это необходимо, конечно) в клиетской проге - ввели бы дополнительное поле, где кодировалась бы сама "сущность". Т.е. район - code == 1, город - code == 2 и т.д.

АргуМенты

То, что у них.*************
Положим не каждую из таких таблиц для разных подзадач в клиентской проге

1) индекс для поля id
2) индекс для поля textval
3) индекс или индексы, гарантирующие уникальность id
4) индекс для защиты целостности ссылок по id

Итого на 100 таблиц 500 объектов

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

1) Для всех таблиц - 100 индексов для защиты целостности ссылок
2) 20 индексов для поля id
3) 20 индексов для поля textval
4) 20 индексов для поля code

Итого на "справочную часть" имеем 180 объектов. И всё не хуже защищено. Надёжность и эффективность - выигрывают. Чем меньше объектов - тем лучше. Кроме того, есть подозрение и в части повышения "быстродействия" из-за страничной организации памяти при работе с таблицами MS SQL Server.

6) О том, почему я так делать не буду (т.е. я намерен оставить всё, как есть у министерцев, и ничего в их структуре не трогать).

Аргументы форумчан, а самое главное, то, что их высказали настоящие профи здесь, на форуме – это и есть аргумент для меня.

ПС.
Спасибо, братцы. Спасибо и за то, что не сказали сразу – ты… ну эта….. иди опохмелись вначале, а затем задавай вопросы.
kladr 03.11.03 15:43  
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 03.11.03 15:52  Количество правок: 2
<"чистая" ссылка> <обсуждение закрыто>
Для хранения всех (ну почти всех) данных, таких как (область,город,улица, дом, индекс) обычно используется пресловутый kladr.

Там две таблицы: street (улицы с домами и с остатками индекса) и kladr (все остальное с началом индекса). Кажись, такая система многих устраивает... Хотя она далека от совершенства и от НФ.

Взять можно, например, здесь
А зря. 03.11.03 10:47  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка> <обсуждение закрыто>
> 6) О том, почему я так делать не буду (т.е. я намерен
> оставить всё, как есть у министерцев, и ничего в их
> структуре не трогать).

Ну я понимаю мешать в одну таблицу справочные и рабочие данные, действительно, ненадо. Но уж справочник сделать одной таблицей однозначно имеет смысл (хоть и не всегда).
В Вашем случае ввести еще одно поле (категорию данных или принадлежность к исходным таблицам).
Если раньше все отдельно было (программа, таблицы, индексы, настройки...), то сейчас все в один файл наровят запихнуть (что Оракл, что Аксесс). Может это и хорошо.
Не зря. 03.11.03 14:01  
Автор: Tee Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
> Ну я понимаю мешать в одну таблицу справочные и рабочие
> данные, действительно, ненадо. Но уж справочник сделать
> одной таблицей однозначно имеет смысл (хоть и не всегда).

Однозначного смысла здесь нет, это мы уже проходили. Конечно можно поизвращаться, но есть много НО (простите за тавтологию).
При таком подходе падает удобство разработки, её скорость,"читаемость" структуры, а так же скорость работы приложения в целом.
Мне знакомы ситуации, когда базы "модернизировались" подобным образом или были написаны так изначально, что либо понять можно только "через ларёк".... .
Вдобавок разработчик примерно за месяц забывает о структуре собственной таблицы и если надо быстро что то сделать (а Access в этом отношении идеален), а программист вдобавок с бодуна .... эффект печален.

> В Вашем случае ввести еще одно поле (категорию данных или
> принадлежность к исходным таблицам).

Одним полем, как мне кажется, обойтись не удастся.
Пересмотр смысла 03.11.03 14:43  
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 03.11.03 15:07  Количество правок: 1
<"чистая" ссылка> <обсуждение закрыто>
> > В Вашем случае ввести еще одно поле (категорию данных
> или
> > принадлежность к исходным таблицам).
>
> Одним полем, как мне кажется, обойтись не удастся.

Давайте рассмотрим пример:
Есть таблица "розничные цены"
И есть таблица "закупочные цены"
Формально - все классно никакие НФ не нарушаются, но реально здесь явная тавтология, т.е. лучше иметь одну таблицу: "Цены" и в ней признак - "закупочная/розничная". В этом случае даже появляется возможность как-то расширить учет (без проблем добавить "оптовая"). При этом мы никаких НФ не нарушаем.

Я полагаю автор корневого поста имел ввиду именно это. Для такой оптимизации надо пересмотреть смысл хранимых данных (дать другие названия таблицам). Грубо говоря, если можешь как-то вразумительно эту таблицу назвать - то все ОК, если нет - то на шаг назад...
Пересмотр смысла 03.11.03 14:55  
Автор: !mm <Ivan Ch.> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Я полагаю автор корневого поста имел ввиду именно это. Для
> такой оптимизации надо пересмотреть смысл хранимых данных
> (дать другие названия таблицам). Грубо говоря, если можешь
> как-то вразумительно эту таблицу назвать - то все ОК, если
> нет - то на шаг назад...

теоретически - да.
допустим, таблица вида:
номенклатурный номер; наименование; цена розничная; цена закупочная
- намного лучше смотрится, чем три таблицы вида
номенклатурный номер; наименование
номенклатурный номер; цена розничная
номенклатурный номер; цена закупочная

оперировать такой таблицей удобней и проще, но совмещать например мух и котлеты (города и улицы) - справочники - в одной таблице, имх, нерационально.

З.Ы. видел БОЛЬШУЮ таблицу, в которой "поехали" данные. записей там было около 80 тысяч, данные поехали слева направо через строку и через-через строку, причем, по непонятной системе.
не говорю, что одиночная таблица от такого застрахована, но восстанавливать данных все же меньше придется (бекапы делались, но кривизну обнаружили лишь через неделю, а за это время много добавилось в таблу, в том чисте и в кривые записи)
Дык это хорошо, имхо. 01.11.03 23:42  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> В той конторе, где я работаю, часть баз данных – «навязана
> сверху». Мы не имеем права что-либо менять в их структуре.
> Вернее в «отчётных форматах». Вопрос о том, что можно
> посоветовать разработчикам «локализованных» версий, что бы
> избавиться от хм. гм-гм (см. ниже) ?
Это, конечно, мое ИМХО, но я всегда стремлюсь справочники раскидывать по отдельным таблицам, причем на каждый справочник - отдельную таблицу. Да, записей в этих таблицах немного, структура одинаковая, а самих таблиц до фига. Зато мухи с котлетами не мешаются. В общем, такую нормализацию БД я считаю правильной.

Собственно, я не вижу особых проблем для локализации такой БД: каждый справочник дублируется, дубликат переводится, после чего в запросах, использующих этот справочник, заменяется имя таблицы с оригиналом на имя таблицы с переводом. При наличии списка таблиц-справочников процесс довольно легко автоматизируется. Или я чего-то не понимаю?
Стиль не потеряешь и не пропьёшь ... . Согласен. 03.11.03 10:21  
Автор: Tee Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
> Это, конечно, мое ИМХО, но я всегда стремлюсь справочники
> раскидывать по отдельным таблицам, причем на каждый
> справочник - отдельную таблицу. Да, записей в этих таблицах
> немного, структура одинаковая, а самих таблиц до фига. Зато
> мухи с котлетами не мешаются. В общем, такую нормализацию
> БД я считаю правильной.

В соответствии с канонами, грамотно.
Респект !
не такой простой вопрос о простых базах 01.11.03 19:17  
Автор: Tee Статус: Незарегистрированный пользователь
<"чистая" ссылка> <обсуждение закрыто>
Вопрос конечно интересный и проблема понятна в "принципе".
Можете мне поверить, гораздо хуже, когда разные данные в находятся в одном "справочнике".
По делу могу посоветовать следующее: разобраться как таблицы связаны с друг в другом (самый капец, когда по составному ключу). Если удастся разобраться в связях таблиц, то тогда можно изменять базу как душе угодно - создавать новые таблицы, запросы, формы и.т.д., не изменяя исходных.
Хотелось бы для большей ясности знать, что за базы, на чём написаны, формат данных ... чем полнее, тем лучше.
не такой простой вопрос о простых базах 02.11.03 12:01  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
> Вопрос конечно интересный и проблема понятна в "принципе".
> Можете мне поверить, гораздо хуже, когда разные данные в
> находятся в одном "справочнике".

Думаю, Вы правы. Хотя об одной таблице речь не идёт. Я пропостил ответ, "в корень" ветки. Посмотрите, плз.
Встречный вопрос - а зачем что-то менять? 01.11.03 15:01  
Автор: !mm <Ivan Ch.> Статус: Elderman
<"чистая" ссылка> <обсуждение закрыто>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach