ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Деревья SQL
9 сообщений из 59, страница 3 из 3
  3  все
Деревья SQL
    #39091569
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
zeon11,

А ВИПРОС их переключает :)
...
Рейтинг: 0 / 0
30.10.2015, 21:32
| Ответить | Цитировать | Написать  
Деревья SQL
    #39091570
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
ViPRos,
...
Рейтинг: 0 / 0
30.10.2015, 21:32
| Ответить | Цитировать | Написать  
Деревья SQL
    #39091584
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
zeon11еревья нужны не для того, чтобы подчеркнуть чью-то подчинённость, а для удобства группировки по каким-то признакам. Я использую их в том числе и для групповых операций. Например, в один клик меняешь параметр у тысяч записей.
для этого нужна обычная группировка по любому признаку.
...
Рейтинг: 0 / 0
30.10.2015, 22:13
| Ответить | Цитировать | Написать  
Деревья SQL
    #39091586
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
zeon11Например, в один клик меняешь параметр у тысяч записей.
Один и тот же параметр у тысяч записей... Разве это не нарушение третьей НФ?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
30.10.2015, 22:38
| Ответить | Цитировать | Написать  
Деревья SQL
    #39091636
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
iscrafmzeon11еревья нужны не для того, чтобы подчеркнуть чью-то подчинённость, а для удобства группировки по каким-то признакам. Я использую их в том числе и для групповых операций. Например, в один клик меняешь параметр у тысяч записей.
для этого нужна обычная группировка по любому признаку.

Да, так и придётся делать, если набор данных не структурирован заранее разработчиком по признаку подчинённости. Если-же он структурирован, то почему-бы этим не воспользоваться?

И тут есть следующие обстоятельства:
1.Если я работаю с плоским списком, я должен его полностью поднять с сервера на клиента, на клиенте произвести группировку (ну например, в гриде), после этого на сервер послать запрос на UPDATE. И не факт, что этот запрос будет всегда простым и быстрым.
2.C деревом, если оно есть, немного проще - не обязательно тянуть всех детей (внуков, правнуков и т.д.) на клиента, достаточно отправить запрос вида
Код: sql
1.
update ...... where PARENT_ID=22


Ну, и всё-таки наличие дерева (или деревьев) в справочнике говорит о проработке разработчиком предметной области. Пользователю немного удобнее работать с деревом.
...
Рейтинг: 0 / 0
31.10.2015, 04:25
| Ответить | Цитировать | Написать  
Деревья SQL
    #39091637
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Dimitry Sibiryakovzeon11Например, в один клик меняешь параметр у тысяч записей.
Один и тот же параметр у тысяч записей... Разве это не нарушение третьей НФ?..

А где нарушение? Таблица, например, ТОВАРЫ.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CREATE TABLE WARE (
    XWARE           DX ,
    XPARENT        DINTLONG DEFAULT -1 ,
    XACC             DINTLONG ,
    XUNIT            DINTSHORT NOT NULL ,
    XMAKER         DINTSHORT ,
    ...........
    NAME            STRING512,
    NDS              DINTSHORT,
   ..............
);
.........
ALTER TABLE WARE ADD FOREIGN KEY (XUNIT) REFERENCES UNIT (XUNIT);
ALTER TABLE WARE ADD FOREIGN KEY (XMAKER) REFERENCES MAKER (XMAKER);
........


По полям XUNIT, XMAKER таблица нормализована, по полю NDS - не нормализована. Но кто не денормализовывал, пусть кинет в меня камень.
Код: sql
1.
2.
3.
update WARE set XUNIT=3 where XPARENT=33 /*  ставим всей группе ед. измерения ЛИТР   */

update WARE set NDS=18 where XPARENT=33 /*  ставим всей группе НДС = 18   */
...
Рейтинг: 0 / 0
31.10.2015, 05:22
| Ответить | Цитировать | Написать  
Деревья SQL
    #39091639
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Dimitry Sibiryakov,

И тут, согласен, несомненно нарушение 3НФ было-бы, если мы жёстко определили, что у XPARENT=33 НДС должен быть только 18%. но это не так. После выполнения
Код: sql
1.
update WARE set NDS=18 where XPARENT=33 /*  ставим всей группе НДС = 18   */

мы можем поменять НДС у любой записи в группе на отличное от 18.

Код: sql
1.
update WARE set NDS=10 where XWARE=123434 /*  ставим одной записи НДС = 10   */
...
Рейтинг: 0 / 0
31.10.2015, 06:03
| Ответить | Цитировать | Написать  
Деревья SQL
    #39091674
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
zeon11
Деревья нужны не для того, чтобы подчеркнуть чью-то подчинённость, а для удобства группировки по каким-то признакам. Я использую их в том числе и для групповых операций. Например, в один клик меняешь параметр у тысяч записей.
Какое дерево не для ... "подчинённость"? Красное?
Все же "Дерево" имеет значение, чтобы, скорее всего, "лазить по нему". Т.е. именно извлекать информацию предполагающее хождение по узлам. В реляционной БД - иерахические запросы или там рекурсивные. Группировка к таковым, вроде не относится.

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

Полноценные иерархические структуры все же в иерархических БД. Там Вы можете лазить по деревьям: язык БД навигационный. А в реляционной БД и иерахичекие запросы не всегда были. И в реляционной алгебре их нет. И то что это у Вас иерархия, Вы может как-то с помощью внешних ключе намекнуть, а не указать явно: мол Дерево.
...
Рейтинг: 0 / 0
31.10.2015, 11:31
| Ответить | Цитировать | Написать  
Деревья SQL
    #39091677
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
zeon11И тут есть следующие обстоятельства:
1.Если я работаю с плоским списком, я должен его полностью поднять с сервера на клиента, на клиенте произвести группировку (ну например, в гриде), после этого на сервер послать запрос на UPDATE. И не факт, что этот запрос будет всегда простым и быстрым.
не совсем понял. Если никто не хочет смотреть на содержимое группы (также как и на содержимое ветки дерева), то просто условие в том же update задается..

кстати:

zeon112.C деревом, если оно есть, немного проще - не обязательно тянуть всех детей (внуков, правнуков и т.д.) на клиента, достаточно отправить запрос вида
Код: sql
1.
update ...... where PARENT_ID=22



таким образом "вытаскиваете" только содержимое узла, на котором установлен курсор. Но обычно пользователей интересует представление типа "Страховые компании, в том числе ДМС, ОМС и т.д." Т.е. в "дереве" должно выполняться рекурсивное чтение. В это случае простейшим условием не обойтись в реляционной структуре. Пример ниже


в данном случае проекция проекта выполнена на подпапку



в таком указанным вами условием не обойтись. PARENTID= и т.п. подходит только для самых элементарных случаев.




zeon11всё-таки наличие дерева (или деревьев) в справочнике говорит о проработке разработчиком предметной области.
конечно не говорит, чаще информация нужна в многомерном представлении все же.
...
Рейтинг: 0 / 0
31.10.2015, 11:51
| Ответить | Цитировать | Написать  
9 сообщений из 59, страница 3 из 3
  3  все
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Деревья SQL
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=39091677&tid=1540450]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 157ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 52ms
get tp. blocked users:
 1ms
others: 14ms
total:  265ms
созд. / загр.: 265ms
x
x
Закрыть


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