ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Реализация справочников
16 сообщений из 41, страница 2 из 2
  2  все
Реализация справочников
    #35526223
khl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
khl
Участник
В варианте 2 надо ввести третью таблицу, в которой будут "сидеть" типы сущностей. Иначе действительно придется запоминать флаги.
...
Рейтинг: 0 / 0
06.09.2008, 23:27
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526306
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
softwarer Николай1Примерно на двадцатом наборе "источник данных - браузер - фильтр - форма", которые отличаются друг от друга только названием таблицы, начинаешь догадываться, что "одной таблицей" было бы куда быстрее...
Как раз про таких людей есть замечательный анекдот.

Идет блондинка по рынку, видит ценник: "Яблочные семечки, $100/десяток". Спрашивает у продавца: - А что так дорого-то?
- Понимаете, девушка, у яблочных семечек есть исключительное качество: кто их есть, тот умнеет.
- Вот как? Здорово. Ну тогда отсчитайте на сто баксов.

Пожевала.. проглотила...
- Странно, вроде ничего в себе не чувствую. За что такие деньги, могла бы купить килограмм яблок, там их куда больше и вышло бы раз в десять дешевле.
- Вот видите, красавица, уже и поумнели!
- Точно!! Работает!!!- (шелест банкнот)- Дайте мне еще три десятка!!

Я бы попросил не хамить.
Двадцать - это была ирония. Вообще-то такие вещи решаются на этапе проектирования. Я работал с системами, построенными и так и так. Так что вполне могу сравнивать.

softwarer
Николай1 softwarerВы когда пишете код, плодите в нем однотипные переменные i, j, k
Если это набор каких-либо счетчиков для статитики
Если Вы не знаете, для чего в программировании применяют переменные i, j и k, то, боюсь, начинать Вам нужно не с этого сайта. Если же вдруг знаете, но предпочитаете подменить тему - это лучше всего свидетельствует о вероятном ответе на заданный вопрос.

Я вообще переменые i,j,k не использую. В книжках их используют в циклах. Что дальше?
...
Рейтинг: 0 / 0
07.09.2008, 09:10
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526310
Кифирчик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кифирчик
Участник
khlВ варианте 2 надо ввести третью таблицу, в которой будут "сидеть" типы сущностей. Иначе действительно придется запоминать флаги.
(и)или enum в клиенте сделать, в соответствии с флагами
enum{
dt_muhi = 1,
dt_tarakany = 2,
...
};
идея хранить справочники в одной таблице, имеет право на жизнь, и будет работать не хуже чем море отдельных таблиц...
всё зависит от специфики приложения
...
Рейтинг: 0 / 0
07.09.2008, 09:15
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526336
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Николай1Я бы попросил не хамить. Двадцать - это была ирония.
Если я правильно понял, что Вы сочли хамством, в чей адрес и почему, то здорово похоже, Вы не поняли смысл наличия этого анекдота в этом месте.

Николай1Примерно на двадцатом наборе "источник данных - браузер - фильтр - форма", которые отличаются друг от друга только названием таблицы, начинаешь догадываться что "одной таблицей" было бы куда быстрее...

Вообще-то такие вещи решаются на этапе проектирования.
Да нет, "такие вещи" решаются на этапе зачатия, на стадии формирования ДНК. Правда, подозреваю, Вы снова не поймете, какие именно "такие".

Николай1Я работал с системами, построенными и так и так. Так что вполне могу сравнивать.
Сравнить опу с пальцем. Понять, что срать пальцами неудобно. Сделать вывод, что руки нахрен не нужны.

Николай1Я вообще переменые i,j,k не использую.
То есть, полезли отвечать на вопрос, который никоим боком к Вам не относится. По принципу "каждой бочке затычка"?
...
Рейтинг: 0 / 0
07.09.2008, 10:57
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526352
beresa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
beresa
Гость
В проектируемой мною базе данных получается, что атрибуты объекта «книга» связаны с помощью внешних ключей со справочниками. Соответственной на текущем уровне разработки у меня в главной таблице хранятся id (тип integer) атрибутов книги (издательство, жанр, назначение, рубрика и т.д.), а сами атрибуты хранятся в отдельных справочниках (см. предыдущий рисунок в конце 1-ой страницы этой темы).
Может лучше все атрибуты хранить в одной (главной) таблицы (т.е. все поля типа integer заменить на поля типа varchar)? Рисунок ниже.
...
Рейтинг: 0 / 0
07.09.2008, 11:39
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526394
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
beresaМожет лучше все атрибуты хранить в одной (главной) таблицы (т.е. все поля типа integer заменить на поля типа varchar)?Зачем ? Такой вариант имеет право на жизнь, но не часто. Во-первых, резко увеличится объем физического пространства, отводимого под информацию на каждую книгу. Может сильно упасть эффективность операций поиска, так как операции сравнения строк будут дольше, чем идентификаторов, обычно представляющих разновидность целых чисел. Кроме того, при выполнении поиска может понадобится больше обращений к диску, что является самой "дорогой" операцией. Кстати, из-за этого же упадет эффективность индексов по таким полям, если таковые будут сделаны.
А если вы еще и от справочников откажитесь, то начнете просто терять информацию. Например, при удалении последней книги определенной рубрики, сама рубрика тоже исчезнет, и в следующий раз, при появлении книги, относящейся к такой рубрике вы должны будете указать заново (и, что важнее, правильно) эту рубрику.
В общем, опять вырисовывается куча недостатков и ни одного явного достоинства. А, самое главное, большинство современных СУБД прекрасно работают со схемой "снежинка" (главной таблицей, окруженной справочниками) которую вам уже рекомендовали.
...
Рейтинг: 0 / 0
07.09.2008, 12:55
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526457
beresa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
beresa
Гость
ChA beresaМожет лучше все атрибуты хранить в одной (главной) таблицы (т.е. все поля типа integer заменить на поля типа varchar)?Зачем ? Такой вариант имеет право на жизнь, но не часто. Во-первых, резко увеличится объем физического пространства, отводимого под информацию на каждую книгу. Может сильно упасть эффективность операций поиска, так как операции сравнения строк будут дольше, чем идентификаторов, обычно представляющих разновидность целых чисел. Кроме того, при выполнении поиска может понадобится больше обращений к диску, что является самой "дорогой" операцией. Кстати, из-за этого же упадет эффективность индексов по таким полям, если таковые будут сделаны.
А если вы еще и от справочников откажитесь, то начнете просто терять информацию. Например, при удалении последней книги определенной рубрики, сама рубрика тоже исчезнет, и в следующий раз, при появлении книги, относящейся к такой рубрике вы должны будете указать заново (и, что важнее, правильно) эту рубрику.
В общем, опять вырисовывается куча недостатков и ни одного явного достоинства. А, самое главное, большинство современных СУБД прекрасно работают со схемой "снежинка" (главной таблицей, окруженной справочниками) которую вам уже рекомендовали.

ChA, спасибо большое за столь подробный ответ. Если буду в Москве, с меня пиво :-)

И у меня снова вопросы по поводу справочников:
1) хотелось узнать, какими лучше сделать правила обновления и удаления записей главной таблицы, связанных внешним ключом со справочниками? (я поставил при обновлении – CASCADE, а при удалении - SET NULL).
2) в клиенте для получения значения атрибутов, которые хранятся в справочниках, думаю использовать не lookup-поля набора данных, а поля непосредственно справочников, полученные в результате запроса:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
select
  l.id_library,
  pl.s_placepublic,
  pub.s_public,
  rub.s_rubric,
  ser.s_series,
  pur.s_purpose,
  gen.s_genre,
  th.s_theme,
  lan.s_language,
  sub.s_subject
from tb_library l
  left join tbs_placepublic pl on (pl.id_placepublic = l.id_placepablic)
  left join tbs_public pub on (pub.id_public = l.id_public)
  left join tbs_rubric rub on (rub.id_rubric = l.id_rubric)
  left join tbs_series ser on (ser.id_series = l.id_series)
  left join tbs_purpose pur on (pur.id_purpose = l.id_purpose)
  left join tbs_genre gen on (gen.id_genre = l.id_genre)
  left join tbs_theme th on (th.id_theme = l.id_theme)
  left join tbs_language lan on (lan.id_language = l.id_language)
  left join tbs_subject sub on (sub.id_subject = l.id_subject)
Такой подход верен?

И ещё, чтобы получить значения всех атрибутов главной таблицы, придётся делать приведенный выше запрос. Смущает, конечно, большое число внутренних левосторонних объединений. Не сильно ли это будет нагружать сервер баз данных и тормозить работу клиента?
...
Рейтинг: 0 / 0
07.09.2008, 14:46
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526471
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
egorych
Участник
beresa1) хотелось узнать, какими лучше сделать правила обновления и удаления записей главной таблицы, связанных внешним ключом со справочниками? (я поставил при обновлении – CASCADE, а при удалении - SET NULL).я, к примеру, запрещаю каскады для справочников. ибо менять PK у справочника - занятие вредное и ненужное, а удалять строку справочника, к которой привязаны данные основной таблицы - вообще злостное нарушение, сродни диверсии
...
Рейтинг: 0 / 0
07.09.2008, 15:02
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526515
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
beresa1) хотелось узнать, какими лучше сделать правила обновления и удаления записей главной таблицы, связанных внешним ключом со справочниками? (я поставил при обновлении – CASCADE, а при удалении - SET NULL).Если у вас связаны по идентификатором, то в чем смысл каскадного обновления ? Как правило, это суррогатные значения, которые никогда не меняются. Пользователь их не видит и ничего о них знать, в общем-то, не должен. Да и каскадный NULL вызывает сомнения. Так что, в целом, я соглашусь с egorych . Первое не нужно, второе - опасно, строки из справочника просто так не удаляются, тем более, если на них есть действующие ссылки из других таблиц.

beresa
2) в клиенте для получения значения атрибутов, которые хранятся в справочниках, думаю использовать не lookup-поля набора данных, а поля непосредственно справочников, полученные в результате запроса:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
select
  l.id_library,
  pl.s_placepublic,
...
  sub.s_subject
from tb_library l
  left join tbs_placepublic pl on (pl.id_placepublic = l.id_placepablic)
...
  left join tbs_subject sub on (sub.id_subject = l.id_subject)
Такой подход верен?

И ещё, чтобы получить значения всех атрибутов главной таблицы, придётся делать приведенный выше запрос. Смущает, конечно, большое число внутренних левосторонних объединений. Не сильно ли это будет нагружать сервер баз данных и тормозить работу клиента?Абсолютно нормально, хотя в ряде случаев запрос в виде
Код: plaintext
1.
2.
3.
4.
5.
select
  l.id_library,
  (SELECT pl.s_placepublic FROM tbs_placepublic pl WHERE pl.id_placepublic = l.id_placepablic),
...
  (SELECT sub.s_subject FROM tbs_subject sub WHERE sub.id_subject = l.id_subject)
FROM tb_library l
может оказаться эффективнее, но это надо проверять в конкретной ситуации и на конкретной СУБД.
Если вы не собираетесь вываливать пользователю на экран сразу тысячи строк, то нагрузка на сервер не будет чрезмерной. Впрочем, это стандартный подход при клиент-серверной архитектуре, пользователь должен получать не больше данных, чем способен осознать, иначе никакие сервера не помогут.
...
Рейтинг: 0 / 0
07.09.2008, 16:37
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526527
beresa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
beresa
Гость
ChA , большое спасибо вам за подробные ответы!
Теперь-то мне становится понятным как правильно нужно всё делать! :-))
...
Рейтинг: 0 / 0
07.09.2008, 17:21
| Ответить | Цитировать | Написать  
Реализация справочников
    #35526673
Николай1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Николай1
Участник
softwarer Николай1Я бы попросил не хамить. Двадцать - это была ирония.
Если я правильно понял, что Вы сочли хамством, в чей адрес и почему, то здорово похоже, Вы не поняли смысл наличия этого анекдота в этом месте.

Николай1Примерно на двадцатом наборе "источник данных - браузер - фильтр - форма", которые отличаются друг от друга только названием таблицы, начинаешь догадываться что "одной таблицей" было бы куда быстрее...

Вообще-то такие вещи решаются на этапе проектирования.
Да нет, "такие вещи" решаются на этапе зачатия, на стадии формирования ДНК. Правда, подозреваю, Вы снова не поймете, какие именно "такие".

Николай1Я работал с системами, построенными и так и так. Так что вполне могу сравнивать.
Сравнить опу с пальцем. Понять, что срать пальцами неудобно. Сделать вывод, что руки нахрен не нужны.

Николай1Я вообще переменые i,j,k не использую.
То есть, полезли отвечать на вопрос, который никоим боком к Вам не относится. По принципу "каждой бочке затычка"?

Настроение плохое?
По делу есть что сказать, или только про ДНК?
...
Рейтинг: 0 / 0
07.09.2008, 21:35
| Ответить | Цитировать | Написать  
Реализация справочников
    #35527496
goodron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
goodron
Участник
beresaМожет лучше все атрибуты хранить в одной (главной) таблицы (т.е. все поля типа integer заменить на поля типа varchar)?
Ни в коем случае! Дополнительно можно прочитать про аномалии при отсутствии 3-ей нормальной формы.
...
Рейтинг: 0 / 0
08.09.2008, 12:32
| Ответить | Цитировать | Написать  
Реализация справочников
    #35548354
Volochkova
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Volochkova
Участник
Все упирается в вопрос терминологии.
Обзови не справочник, а перечисления.
Пока это таблица вида
Код - Код родителя - Название - Текстовое свойство - Числовое Свойство
То пишем в таблицу перечислений
Тип перечисления - Код - Код родителя - Название - Текстовое свойство - Числовое Свойство
Как стало тесно, выделяем в справочник. Где уже все будет расписано.
Конкретные поля, свойства, обработки, формы на выборку, на редактирование и прочее.


Вне зависимости от того как хранить, рекомендую на таблицу тут же сделать View и обозвать ее как надо. Тогда перенеся перечисления в справочник, все что надо, подправить View.
А в новый справочник вливать с кодами в таблице перечислений.
Все отчеты как работали так и будут работать.
Зато все будет работать, при минимуме затрат. .
...
Рейтинг: 0 / 0
19.09.2008, 11:06
| Ответить | Цитировать | Написать  
Реализация справочников
    #35548629
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naf
Участник
Может кому пригодится
http://mynaf.narod.ru/ObjectQuery.rtf%5D%7C>]http://mynaf.narod.ru/ObjectQuery.rtf]|> http://mynaf.narod.ru/ObjectQuery.rtf" TARGET="_blank">Объектные запросы
С уважением, Naf
...
Рейтинг: 0 / 0
19.09.2008, 12:20
| Ответить | Цитировать | Написать  
Реализация справочников
    #35548632
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naf
Участник
NafМожет кому пригодится
http://" TARGET="_blank">http://mynaf.narod.ru/ObjectQuery.rtf]http://mynaf.narod.ru/ObjectQuery.rtf" TARGET="_blank">Объектные запросы
С уважением, Naf

блин, Объектные запросы
...
Рейтинг: 0 / 0
19.09.2008, 12:21
| Ответить | Цитировать | Написать  
Реализация справочников
    #35548647
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
VolochkovaВсе упирается в вопрос терминологии.
Обзови не справочник, а перечисления.Это только кажется, что если адрес назвать "Геопривязкой", от этого он изменится.
Такая терминология только ЗАПУТАЕТ тех кто будет рзбираться с этой системой, а свойства этой сущности никак не изменятся.

VolochkovaКак стало тесно, выделяем в справочник. Где уже все будет расписано.
Конкретные поля, свойства, обработки, формы на выборку, на редактирование и прочее.Будет поздно пить боржоми.
Придется не просто создать отдельную таблицу, где все будет как надо, а кроме этого переписать программы и отчеты, которые используют старый справочник.

VolochkovaВне зависимости от того как хранить, рекомендую на таблицу тут же сделать View и обозвать ее как надо. Тогда перенеся перечисления в справочник, все что надо, подправить View. А в новый справочник вливать с кодами в таблице перечислений.
Все отчеты как работали так и будут работать.
Зато все будет работать, при минимуме затрат. .А что, создание VIEW и таблицы - это сильно отличающиеся по затратам операции?
Я бы сказал, что CREATE OR REPLACE VIEW писать дольше, чем CREATE TABLE.
...
Рейтинг: 0 / 0
19.09.2008, 12:25
| Ответить | Цитировать | Написать  
16 сообщений из 41, страница 2 из 2
  2  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Реализация справочников
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=35526336&tid=1543653]:
 0ms
get settings:
 5ms
get forum list:
 9ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 178ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 50ms
get tp. blocked users:
 1ms
others: 200ms
total:  457ms
созд. / загр.: 457ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]