ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Плюсы и минусы иерархического способа хранения данных
232 сообщений из 232, показаны все 10 страниц
  все  
Плюсы и минусы иерархического способа хранения данных
    #33626035
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Есть данные которые можно хранить в одной таблице как иерархические или разбить на несколько таблиц. Я так думаю, что все зависит от конкретики. Например, если речь идет о географических точках, то можно сделать и разные таблицы (ТОЧКИ, РАЙОНЫ, ОБЛАСТИ). Т.к. уровней всего 3. Но там где пока неизвестно сколько таких уровней и их может быть много, лучше применить иерархический способ. Но это пока только в теории. Если кто знает как лучше и какие подводные камни могут быть - прошу высказаться.
...
Рейтинг: 0 / 0
26.03.2006, 22:32
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33626165
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
Прочитал 3 раза. Все-равно ничего не понял. О чем речь-то? Про Spatial Data?
Нет - делай дерево...
...
Рейтинг: 0 / 0
27.03.2006, 06:19
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33626170
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Пардон, а что такое Spatial Data?
...
Рейтинг: 0 / 0
27.03.2006, 06:40
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33626528
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
даже с районами, областями и нас-пунктами не все так хорошо. бо есь пункты областного подчинения (т.е. не так лехко развести вторичные ключи при раздельном хранении). дерево и тут, имхо, часто удобнее.
...
Рейтинг: 0 / 0
27.03.2006, 10:59
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33626539
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
к минусам можно отнесть то, что не всякая субд поддерживает иерархические запросы. Придется либо писать рекурсивные процедуры, либо отягощаться дополнительными исхитрениями с тем, чтобы, к примеру, получить всю иерархию некоего узла стандартным SQL.
...
Рейтинг: 0 / 0
27.03.2006, 11:03
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33627003
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nik_x
Участник
КДПардон, а что такое Spatial Data?

Картография. (ГИС)
...
Рейтинг: 0 / 0
27.03.2006, 13:31
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33627023
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
КДПлюсы и минусы иерархического способа хранения данных
Имхо критерий достаточно прост. Нужно сравнить количество и сложность операций, выполняемых "со всеми строками данных независимо от конкретного типа" и количество выполняемых поотдельности с "городами", "районами" и так далее. Если много общего - удобно хранить в общей таблице. Если большинство специфичного - скорее всего выгоднее будет разнести по разным.
...
Рейтинг: 0 / 0
27.03.2006, 13:38
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33630180
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
>Имхо критерий достаточно прост. Нужно сравнить количество и сложность операций, выполняемых "со всеми строками данных независимо от конкретного типа" и количество выполняемых поотдельности с "городами", "районами" и так далее. Если много общего - удобно хранить в общей таблице. Если большинство специфичного - скорее всего выгоднее будет разнести по разным.

А вот тут, если можно, поподробнее... Мне что-то пока сложно сравнить. Могу сказать, что из этих отдельных таблиц можно сотворить поля со списками с динамическим обновлением (научили как), а также строить всякие запросы. Дерево займет много места на форме (по сравнению с 3 ComboBox'ами), да и не научился я пока с деревьями работать. А по логике вроде бы да, раз в природе эти данные существуют как иерархические, по крайней мере, на карте, то и хранить их надо в одной таблице. У меня тут сейчас похожая ситуация, но там точно все ясно, поскольку отдельными таблицами никак нельзя. Да и вообще на схеме уже столько таблиц, что черт ногу сломит.
...
Рейтинг: 0 / 0
28.03.2006, 16:19
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33630230
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
КДМне что-то пока сложно сравнить. Могу сказать, что из этих отдельных таблиц можно сотворить поля со списками с динамическим обновлением (научили как), а также строить всякие запросы. Дерево займет много места на форме (по сравнению с 3 ComboBox'ами), да и не научился я пока с деревьями работать.
Первое и самое главное. Запомните это, распечатайте, повесьте на стену и ежедневно проверяйте, пока не прочувствуете на подсознательном уровне:

Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот

Увязывать их - одна из самых больших глупостей, которые могут быть сделаны проектировщиком. Когда мы говорим о разработке например клиент-серверного приложения, мы говорим о том, что делаем два независимых взаимодействующих компонента, каждый из которых решает свои задачи. Комбобоксы можно заполнять из разных таблиц и комбобоксы можно заполнять из разных записей одной таблицы. Дерево можно заполнять из одной таблицы и можно заполнять из разных таблиц. Это вопрос реализации клиента и не особо сложный. Более того; в любой момент времени может быть принято решение переделать клиента с комбобоксов на treeview или наоборот, и это никак и никоим образом не должно повлиять на сервер.

КДА по логике вроде бы да, раз в природе эти данные существуют как иерархические, по крайней мере, на карте, то и хранить их надо в одной таблице.
Логика реального мира - опасный инструмент, если пытаться напрямую отразить ее в БД. Допустим, в реальном мире вряд ли существует объект "Пьяный розовый слон". Но может оказаться, что эта виртуальная сущность очень удобна для решения той или иной задачи и она должна быть реализована в БД.

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

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

КДДа и вообще на схеме уже столько таблиц, что черт ногу сломит.
Именно поэтому в любом приличном инструменте есть возможность делать отдельные диаграммы для разных фрагментов схемы. Логика тут та же, что и в проекте на тысячу файлов - это реальность, которую нужно учиться организовать удобным для работы образом.
...
Рейтинг: 0 / 0
28.03.2006, 16:35
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33630922
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
softwarer, огромное спасибо!
Простым и понятным языком объяснено то, что у Дейта сложно или я еще не дочитал до этого места.
Никаких ТЗ и т.п. нет - база для личного пользования, разрабатывается мной и использовать буду тоже только я. Так что как все сам сделаю, так и будет.
...
Рейтинг: 0 / 0
28.03.2006, 22:13
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33631749
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
softwarer Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот Но не могут противоречить друг другу. Т.е на самом деле зависят - от общей основы.
...
Рейтинг: 0 / 0
29.03.2006, 11:54
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33633450
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Так все-таки, какие будут итоги? Какие плюсы и минусы?
...
Рейтинг: 0 / 0
29.03.2006, 18:33
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #33633507
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Я не очень понимаю, что Вы подразумеваете под противоречием.

Имхо существует единственное принципиальное ограничение - клиент [не привлекая других источников] не может оперировать информацией, отсутствующей в БД. Во всем остальном он свободен; он может взять любую информацию из БД и перекрутить ее как угодно. И исходя из своих задач, таки может именно что перекрутить - например, какой-нибудь OLAP-анализ непосредственно над данными учетной системы.

Разумеется, эта свобода ограничивается практическими потребностями, критерием оптимальности. На макроуровне вполне естественно ожидать определенных соотношений, скажем "модуль клиента - набор таблиц БД", а часто и "форма - таблица". Но с моей точки зрения крайне важно понимать причины и следствия этих соотношений; надо понимать, что это осознанный выбор, который можно и нужно изменить в тех случаях, когда он неудачен.
...
Рейтинг: 0 / 0
29.03.2006, 19:01
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
Плюсы и минусы иерархического способа хранения данных
    #34541109
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Все осложняется еще и тем, что частенько присутствуют не административные, а географические указания типа: "Нижняя Волга", "междуречье Волги и Урала", "среднее течение Дона". Как с этим быть?
...
Рейтинг: 0 / 0
22.05.2007, 06:23
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34541215
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mir
Участник
КДПростым и понятным языком объяснено то, что у Дейта сложно или я еще не дочитал до этого места.
А что, неужто у Дейта раздел про трёхуровневую модель ANSI/SPARC так сложно для вас написан? А это оно и есть.
...
Рейтинг: 0 / 0
22.05.2007, 08:29
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34541478
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
КДЕсть данные которые можно хранить в одной таблице как иерархические или разбить на несколько таблиц.
есть два вида иерархии: 1. между сущностями одного типа и 2.между разными сущностями. Разница в реализации принципиальная. Вам что надо ?
...
Рейтинг: 0 / 0
22.05.2007, 10:41
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34542039
Waytac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Waytac
Гость

softwarerСтруктура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот
Это правильно написано, да и всё остальное у него.

КДВсе осложняется еще и тем, что частенько присутствуют не административные, а географические указания типа: "Нижняя Волга", "междуречье Волги и Урала", "среднее течение Дона". Как с этим быть?
Это всё должно реализовываться по общей схеме. Тем более, что если не требуется привязка к существующим классификаторам адресов (КЛАДР и т.п.).
Есть универсальные схемы по реализации структуры адресов. Если интересно, то стучитесь 309-134-873, что бы в конфе не флудить.
...
Рейтинг: 0 / 0
22.05.2007, 13:04
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34542730
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
В реляционных БД никаких иерархий нет. Иерархия может быть образована только в процессе сортировки, соединения и отображения записей.

С помощью иерархической сортировки мы получаем упорядоченную выборку в которой сведения относящиеся к одному объекту находятся в нескольких записях. Сортировки применяются к выборкам однотипных записей.

Например структура каталога в иерархическом запросе может выглядеть так:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
level name
1    C:
2    Administrator
2    Program Files
2    Documents and Setings
3    Administrator
3    All Users
2    Windows

Работать с такой выборкой реляционными методами весьма сложно. Например не так просто найти каталог C:\Documents and Setings\Administrator, а не C:\Administrator. К +++ можно отнести прозвольную глубину вложений и малое дублирование данных.

С помощью соединения таблиц (в том числе и самосоединения) мы молучаем набор записей, каждая из которых полностью характеризует объект. К такой выборке применимы обычные возможности SQL. К сожалению количество характеристик объекта в данном случае ограничено, но это ограничение обходится динамическим SQL.
...
Рейтинг: 0 / 0
22.05.2007, 15:43
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34543780
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
2 mod
> есть два вида иерархии: 1. между сущностями одного типа и 2.между разными сущностями. Разница в реализации принципиальная. Вам что надо ?
Дык... Если бы я знал что надо. Ну для начала давайте разберемся, одного ли это типа сущности (ТОЧКИ, РАЙОНЫ, ОБЛАСТИ) или нет? Если рассматривать их с точки зрения использования в моей базе то да, одного. Рассматриваются они в контексте привязки к ним объектов. Но не напрямую, а опосредованно. Т.е. объекты напрямую связаны только с ТОЧКАМИ, которые входят в РАЙОНЫ, а те, в свою очередь, в ОБЛАСТИ. Если рассматривать эти объекты с точки зрения ГИС, то это разные объекты: ТОЧКИ - точечные, а РАЙОНЫ и ОБЛАСТИ - полигоны.

2 mcureenab
Ну да, конечно, нет. Я просто имел ввиду классические таблицы с полями ID, PARENT.

2 Waytac
Не думаю, что это связано с КЛАДР. Произвольные полигональные объекты и классификатор адресов? Думаю, это многим будет интересно, так что можно и в конфе. Тут еще не так флудили.
...
Рейтинг: 0 / 0
22.05.2007, 20:56
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34543855
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
КДЕсли рассматривать эти объекты с точки зрения ГИС, то это разные объекты: ТОЧКИ - точечные, а РАЙОНЫ и ОБЛАСТИ - полигоны.

Точки можно смело исключать, ибо точка понятие чисто абстрактное. В природе точечных объектов не существует. Для рисования карты РАЙОНЫ и ОБЛАСТИ, это полигоны отличающиеся обозначением границы. Если считать, что область это множество районов, то получить область можно простым объединением районов в неё входящих, но на практике проще районы и области описать раздельно и привязать к разным слоям карты, а затем для просмотра выбирать слой с нужным уровнем детализации объектов. В общем, в плане организации данных можно обойтись без иерархии.
...
Рейтинг: 0 / 0
22.05.2007, 21:32
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34544783
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
КДДык... Если бы я знал что надо. Т.е. объекты напрямую связаны только с ТОЧКАМИ, которые входят в РАЙОНЫ, а те, в свою очередь, в ОБЛАСТИ.
Итого сущность одна - ТОЧКИ (со всеми своими св-ми), а РАЙОНЫ-ОБЛАСТИ - это иерархический классификатор для точек. Таких классификаторов м.б. несколько. Точки првязаны к листьям классификатора.
...
Рейтинг: 0 / 0
23.05.2007, 11:15
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34548858
Waytac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Waytac
Гость
To КД
В начале непонятно было о какой предметной области точно идёт речь, поэтому упомянул КЛАДР.

А в общем вы сами ответили на свой вопрос в первом же топики. Приведу:
КД... Я так думаю, что все зависит от конкретики. ...
Конкретную реализацию имеет смысл рассматривать, только для конкретного ТЗ, т.к. вариантов может быть куча.
Приведите точное описание задачи.
...
Рейтинг: 0 / 0
24.05.2007, 15:37
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34548896
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
мод КДДык... Если бы я знал что надо. Т.е. объекты напрямую связаны только с ТОЧКАМИ, которые входят в РАЙОНЫ, а те, в свою очередь, в ОБЛАСТИ.
Итого сущность одна - ТОЧКИ (со всеми своими св-ми), а РАЙОНЫ-ОБЛАСТИ - это иерархический классификатор для точек. Таких классификаторов м.б. несколько. Точки првязаны к листьям классификатора.
Это везде так. Надо давать возможность классифицировать как вздумается. И классификатор не объязательно должен включать в себя только один тип (Вещи(хорошие вещи(женщины, диваны, чача, шашлык),плохие вещи(старость, безденежье, слабость)). :)
...
Рейтинг: 0 / 0
24.05.2007, 15:46
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34549605
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
2 mcureenab
> точка понятие чисто абстрактное
> В природе точечных объектов не существует.
Не такое уж абстрактное это понятие – точка. Все зависит от масштабов систем, с которыми мы работаем. Например, в масштабах материков и океанов (и даже областей и районов) площадь 1 м2 можно смело считать точечным объектом. Как справедливо отметил softwarer: "Допустим, в реальном мире вряд ли существует объект "Пьяный розовый слон". Но может оказаться, что эта виртуальная сущность очень удобна для решения той или иной задачи и она должна быть реализована в БД. Логика реального мира - опасный инструмент, если пытаться напрямую отразить ее в БД."

2 мод
Собственно говоря, почти так оно сейчас и есть. Только районы и области в разных таблицах. Ну да слить их в одну иерархическую (да простит меня mcureenab) несложно. Другое дело, что это у меня объекты привязаны к точкам, а, скажем, в литературных источниках они могут быть привязаны и к районам и к областям, и, что самое противное, к произвольным полигональным объектам. Сделав общую иерархическую таблицу со ссылками для каждой записи на тип объекта, к которому она принадлежит, я хотя бы более-менее просто могу обеспечить ссылочную целостность между объектами и географическими объектами (точками, районами, областями). Но произвольные полигональные объекты и на такую структуру не ложатся. А про какие НЕСКОЛЬКО классификаторов вы говорите? Может быть, тут кроется ключ?

2 Waytac
Ну, пожалуй, полное и подробное описание задачи приводить ни к чему - долго и утомительно. Изложу то, что на мой взгляд, повлияет на принятие решения. Итак, есть объекты - экземпляры зоологических коллекций, которые были собраны в таких-то точках, относящихся к таким-то районам и т.д. Эти экземпляры как-то называются, например, гадюка, барсук и т.д. Таким образом, в БД есть запись: Экземпляр № 625 Гадюка обыкновенная, собрана там-то (точка), тогда-то и такой-то. В литературных источниках авторы указывают, как правило, не конкретные экземпляры и точки, а в общем: "гадюка обыкновенная встречается в лесах среднего течения Дона". Задача все та же - как именно хранить географические данные?

2 Сахават Юсифов
В этом топике мы не будем обсуждать права, т.к. база для личного пользования. Оставим все мысли по этому вопросу для топика "база товаров - у кого как...". Ладно?
...
Рейтинг: 0 / 0
24.05.2007, 19:08
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34549624
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
softwarer
Первое и самое главное. Запомните это, распечатайте, повесьте на стену и ежедневно проверяйте, пока не прочувствуете на подсознательном уровне:

Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот

Увязывать их - одна из самых больших глупостей, которые могут быть сделаны проектировщиком.

Весьма не профессиональное высказывание. Удружил "начинающему".
...
Рейтинг: 0 / 0
24.05.2007, 19:16
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34549642
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
мод КДДык... Если бы я знал что надо. Т.е. объекты напрямую связаны только с ТОЧКАМИ, которые входят в РАЙОНЫ, а те, в свою очередь, в ОБЛАСТИ.
Итого сущность одна - ТОЧКИ (со всеми своими св-ми), а РАЙОНЫ-ОБЛАСТИ - это иерархический классификатор для точек. Таких классификаторов м.б. несколько. Точки првязаны к листьям классификатора.
Ага. Только скорее "квадратики" какие-нибудь, а не точки.
...
Рейтинг: 0 / 0
24.05.2007, 19:27
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34549709
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
КДЗадача все та же - как именно хранить географические данные?

Для географических данных существуют специальные структуры. Например для СУБД Оракл есть Spatial Data. Как они хранятся, очень хорошо написано в соответсвующей документации.
...
Рейтинг: 0 / 0
24.05.2007, 20:04
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34549717
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Я так понял, нужно иметь карторгафические данные, т.е. множество фигур или точек, которые организованы, сгруппированы и классифицированы способами, которые приняты в области картографии и анкетные данные, которые увязывают и классифицируют разнообразные сведения воедино способами принятыми в твоей предметной области.
...
Рейтинг: 0 / 0
24.05.2007, 20:15
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34550080
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
2 Бред
А по-моему, softwarer абсолютно правильно все написал.

2 mcureenab
> Для географических данных существуют специальные структуры. Например для СУБД Оракл есть Spatial Data. Как они хранятся, очень хорошо написано в соответсвующей документации.

Про Spatial Data в Oracle я знаю, но что поделать - у меня Access. Я ведь, наверное, не смогу в нем сделать аналог Spatial Data, даже если прочитаю документацию?

> Я так понял, нужно иметь карторгафические данные, т.е. множество фигур или точек, которые организованы, сгруппированы и классифицированы способами, которые приняты в области картографии и анкетные данные, которые увязывают и классифицируют разнообразные сведения воедино способами принятыми в твоей предметной области.

Да, все правильно.
...
Рейтинг: 0 / 0
25.05.2007, 06:03
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34550796
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
КД2 Бред
А по-моему, softwarer абсолютно правильно все написал.

Я про "ВСЕ" не говорил, а про то, что сказал: как раз абсолютно не правильно. Такой подход бессмысленно удорожает проект, продукт и весь его жизненный цикл.
...
Рейтинг: 0 / 0
25.05.2007, 11:53
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34552295
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
КД
> Для географических данных существуют специальные структуры. Например для СУБД Оракл есть Spatial Data. Как они хранятся, очень хорошо написано в соответсвующей документации.

Про Spatial Data в Oracle я знаю, но что поделать - у меня Access. Я ведь, наверное, не смогу в нем сделать аналог Spatial Data, даже если прочитаю документацию?



В доке описан принцип. Конечно Spatial Data это не хвост собачий, но тебе скорее всего и не нужны все его возможности. В твоём случае для картографии имеет смысл использовать коробочное специализированное ПО, а в Access'e хранить только специфичные для твоей предметной области данные: названия географических областей, координаты точек поимки конкретных змей.
...
Рейтинг: 0 / 0
25.05.2007, 17:28
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34552712
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
2 Бред
Ну пусть не все и пусть не абсолютно, но про то, что модель классов от интерфейса не должна зависеть - это уж точно. А еще лучше, когда интерфейс вообще потом разрабатывается. Я сам столкнулся с этим, когда много раз переделывал разные формы, запросы и т.д. только потому, что не все учел при проектировании. Как это отразится на "стоимости" продукта - мне совершенно все равно, как я уже много раз писал - БД для личного пользования. Я не быстрее хочу сделать, а лучше и научиться правильным методам.

2 mcureenab
Это понятно, что "Spatial Data это не хвост собачий". Также ясно, что понадобится мне не так уж много возможностей (а впрочем, зарекаться я уже боюсь). Для картографии, конечно, понадобится коробочное ПО. Думаю, что для этой цели буду использовать MapInfo.
Но! MapInfo позволяет выводить на карту точки, которые, конечно, должны быть (и есть) в БД. MapInfo позволяет работать с этими точками. Но соотнести указания в литературе с произвольными полигональными объектами MapInfo не сможет. Эти данные туда не выгружаются, потому как сначала их надо как-то задать и как-то хранить. Вот и вопрос - как? Предположим, я сделаю все произвольные полигоны в слоях. Но я же не смогу связать их с указаниями! Насколько я знаю, в MapInfo нет ключей объектов. Да если бы и были, как бы я отразил это в структуре БД?
...
Рейтинг: 0 / 0
25.05.2007, 19:45
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34552774
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Не спец в MapInfo.

Могу предположить, что картографические объекты проще и эффективнее хранить в виде BLOB в формате, который непосредственно воспринимает MapInfo. Типа - (id, map_data blob). BLOB позволит компактно хранить данные и быстро выгружать их в MapInfo для отображения и решения других задач. Очевидный минус - без MapInfo с такими данными ты ничего практически значимого сделать не сможешь. С другой стороны писание своей Spatial подсистемы на Access представляется достаточно сложной задачей из области скрещивания бульдога с носорогом. И дело даже не в сложности программирования, а в том что картография связана с большим числом маленьких объектов (точек, линий и т.п.). Access просто не поднимет БД с таким количеством строк.

Что можно делать с картами в blob?

1. Отобразить на карте районов точки в которых были найдены артефакты. В MapInfo выводим из blob карты районов и точки с надписями и смотрим на экран.

2. По координатам точки найти район, в котором эта точка находится. В этом случае выгружаем в MapInfo карту районов, и запрашиваем у него id района в котором находится данная точка. MapInfo наверняка такие функции имеет.
...
Рейтинг: 0 / 0
25.05.2007, 20:28
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34553034
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
Бред softwarer
Первое и самое главное. Запомните это, распечатайте, повесьте на стену и ежедневно проверяйте, пока не прочувствуете на подсознательном уровне:

Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот

Увязывать их - одна из самых больших глупостей, которые могут быть сделаны проектировщиком.

Весьма не профессиональное высказывание. Удружил "начинающему".
Вы намекаете что структуры данных должны зависеть от пользовательского интрефейса
и это, якобы удешевит проект, продукт и весь жизненный цикл?
...
Рейтинг: 0 / 0
26.05.2007, 09:23
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34555295
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
tchingiz Бред softwarer
Первое и самое главное. Запомните это, распечатайте, повесьте на стену и ежедневно проверяйте, пока не прочувствуете на подсознательном уровне:

Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот

Увязывать их - одна из самых больших глупостей, которые могут быть сделаны проектировщиком.

Весьма не профессиональное высказывание. Удружил "начинающему".
Вы намекаете что структуры данных должны зависеть от пользовательского интрефейса
и это, якобы удешевит проект, продукт и весь жизненный цикл?

Что тут намекать, то? Такого впринципе быть не может. Изменение структуры БД всегда влечёт за собой изменение приложений, иначе это изменение будет бесполезным. Т.е. приложение всяко зависит от структуры БД. Вопрос обратной зависимости не столь однозначный. Обычно БД всё таки оптимизируют для использования с конкретными приложениями. Ведь БД нужна не только чтобы хранить сведения (для этого есть более подходящие средства), но в первую очередь использовать их для решения задач. Неплохо, когда структура БД позволят делать это легко и непринуждённо.
...
Рейтинг: 0 / 0
28.05.2007, 14:22
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34555313
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenab
Меня не удивляет, когда люди не умеют думать. Меня не удивляет, когда люди не умеют читать. Но меня продолжает удивлять, когда вроде бы умеющие думать люди не умеют читать.
...
Рейтинг: 0 / 0
28.05.2007, 14:28
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34555377
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
softwarer mcureenab
Меня не удивляет, когда люди не умеют думать. Меня не удивляет, когда люди не умеют читать. Но меня продолжает удивлять, когда вроде бы умеющие думать люди не умеют читать.

Возможно, стереотипы мышления (такие как категории Oracle Forms) не позволяют мне адекватно донести прочитанное до своего сознания. Если коротко - моя твоя не понимай.
...
Рейтинг: 0 / 0
28.05.2007, 14:49
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34555598
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
tchingiz Бред softwarer
Первое и самое главное. Запомните это, распечатайте, повесьте на стену и ежедневно проверяйте, пока не прочувствуете на подсознательном уровне:

Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот

Увязывать их - одна из самых больших глупостей, которые могут быть сделаны проектировщиком.

Весьма не профессиональное высказывание. Удружил "начинающему".
Вы намекаете что структуры данных должны зависеть от пользовательского интрефейса
и это, якобы удешевит проект, продукт и весь жизненный цикл?

Ровно наоборот. Я намекаю, что пользовательский интерфейс должен зависеть от концептуальной модели данных (то есть полностью ей определяться), и, соответственно, логическая модель не должна отличаться от концептуальной.
...
Рейтинг: 0 / 0
28.05.2007, 15:50
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34555621
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
КД2 Бред
Ну пусть не все и пусть не абсолютно, но про то, что модель классов от интерфейса не должна зависеть - это уж точно. А еще лучше, когда интерфейс вообще потом разрабатывается. Я сам столкнулся с этим, когда много раз переделывал разные формы, запросы и т.д. только потому, что не все учел при проектировании. Как это отразится на "стоимости" продукта - мне совершенно все равно, как я уже много раз писал - БД для личного пользования. Я не быстрее хочу сделать, а лучше и научиться правильным методам.


Вы учитесь не правильным методам. И сами с этим столкнулись, "много раз переделывая разные формы, запросы и т.д.". И Вы переиначили достаточно очевидную вещь: интерфейс должен (даже обязан) "зависеть" от ..., а не наоборот.
...
Рейтинг: 0 / 0
28.05.2007, 15:55
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34555665
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
Что же касается "зависимости структуры данных от интерфейса", то она тоже имеет место на уровне метамодели, так учат в университетах.
...
Рейтинг: 0 / 0
28.05.2007, 16:03
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34555735
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Что же касается "зависимости структуры данных от интерфейса",
> то она тоже имеет место на уровне метамодели, так учат в университетах

Бросайте такие университеты. Ничему хорошему Вас там не научат.
...
Рейтинг: 0 / 0
28.05.2007, 16:20
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34555770
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenabЕсли коротко - моя твоя не понимай.
Моя говорит в общем стандартную вещь - конструкция двигателя автомобиля не должна зависеть от цвета его кузова, равно как и наоборот. Если я - пользователь - говорю "хорошая машина, все замечательно, вот только сделайте мне две дверцы вместо четырех" - инженеры не должны "заодно" менять инжектор на дизель.

"Как хранить данные" и "как отобразить данные" - два разных вопроса, в поиске ответа на который рассматриваются принципиально разные факторы. Допустим, у нас есть логические понятия "Страна", "Регион" и "Город" - кажется, мы начинали именно с них. В этом случае "архитектор БД" будет решать, делать ли три справочника либо один иерархический. А "дизайнер UI" будет решать, как делать выбор города - трехуровневым деревом или, допустим, тремя комбобоксами. Между ответами на эти вопросы нет и не может быть прямой связи (косвенно они, конечно, связаны через общую задачу и общий фрагмент модели). Как простая иллюстрация к отсутствию прямой связи - если клиент скажет "не хочу дерево, хочу комбобоксы" - никто не должен бежать к архитектору БД с криком "режь свою иерархическую таблицу натрое".
...
Рейтинг: 0 / 0
28.05.2007, 16:27
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556018
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
softwarer mcureenabЕсли коротко - моя твоя не понимай.
Моя говорит в общем стандартную вещь - конструкция двигателя автомобиля не должна зависеть от цвета его кузова, равно как и наоборот. Если я - пользователь - говорю "хорошая машина, все замечательно, вот только сделайте мне две дверцы вместо четырех" - инженеры не должны "заодно" менять инжектор на дизель.


Одно дело - наши желания, другое - наши возможности. Если дизтопливо оставляет пятна на краске, то нужно либо бензиновый двигатель ставить, либо краску менять и т.п..

Cредства разработки класса Builder на современном этапе создают довольно тесную связь между структурой данных и их визуальным представлением. Проектируя части системы с этим фактом нельзя не считаться. Если встречное движение архитектора БД и дизайнера UI позволяет создать сбалансированное решение, то почему бы не делать так? Иначе каждый будет горд своим гениальным и абсолютно правильным решением, а система в целом никогда не заработает.
...
Рейтинг: 0 / 0
28.05.2007, 17:44
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556156
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenabОдно дело - наши желания, другое - наши возможности.
Если разработчик импотентен, между желаниями пользователя и результатом действительно окажется непреодолимая пропасть, и гордиться тут совершенно нечем. Профессионал - как раз тот, кто своими "возможностями" связывает желания с результатом, в редких случаях объясняя, что то или иное желание может быть куплено только ценой ухудшения в другом месте. В идеализированной ситуации (разработчик проводит обследование пока не сочтет его полностью законченным, полностью свободно выбирает инструменты итп.) как раз количество таких вот возникших впоследствии "придется жертвовать" и определяет профессионализм команды. При этом вышеназванный принцип - один из тех, может быть основной из тех, которые как раз позволяют реализовать этот профессионализм.

На самом деле все очень просто. Как Вы наверняка помните, "лень - двигатель прогресса". Проблема в том, что есть два принципиально разных вида лени:

1. Мне лень делать плохо и потом мучиться-переделывать.
2. Мне лень делать хорошо.

Так вот, двигателем прогресса является только одна из них.

mcureenabЕсли дизтопливо оставляет пятна на краске, то нужно либо бензиновый двигатель ставить, либо краску менять и т.п..
Все правильно. Собственно, как раз иллюстрация к сказанному выше - если есть проблема, надо либо исключить контакт топлива с краской, либо найти устойчивую краску того же цвета, либо .. либо .. либо .. и только на самом последнем этапе - прийти к пользователю и сказать:

mcureenabCредства разработки класса Builder
Это, простите, что такое?

mcureenabна современном этапе создают довольно тесную связь между структурой данных и их визуальным представлением.
Не верю (c). Мне трудно обсуждать некие неизвестные продукты, но я совершенно уверен, что толковые средства, примененные с участием мозгов, позволяют добиться хорошего результата.

Собственно, представьте себе, что у Вас в СУБД выполняются:

Код: plaintext
1.
2.
3.
select * from Country
select * from Region
select * from City
select * from Hierarchical_Geo_Dictionary

Будьте так любезны, скажите пожалуйста, что из названного - таблицы, что - представления, и с чьей именно структурой данных намертво связано визуальное представление в "средствах разработки класса Builder"?

mcureenabПроектируя части системы с этим фактом нельзя не считаться. Если встречное движение архитектора БД и дизайнера UI позволяет создать сбалансированное решение, то почему бы не делать так?
Потому что оно будет не "сбалансированным", а "сильно связанным как раз в том месте, где этого не следует делать".

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

Код: plaintext
1.
- Почему втрое упала скорость ночного job-а, занимающегося экспортом (импортом, обсчетом,...) данных из вашей базы в нашу?
- Потому что мы изменили внешний вид нашего GUI-клиента, которого вы в глаза не видели.

mcureenabИначе каждый будет горд своим гениальным и абсолютно правильным решением, а система в целом никогда не заработает.
Если разработчики системы потентны на уровне "а еще я в нее ем" - то начинать следует вовсе не со структуры данных.
...
Рейтинг: 0 / 0
28.05.2007, 18:37
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556333
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
softwarer
mcureenabCредства разработки класса Builder
Это, простите, что такое?


С++ Builder, Delphi, Oracle Forms. Т.е. средства построения приложений из готовых блоков. В идеале, для строительства приложения не требуется писать ни одной строчки кода.

softwarer
mcureenabна современном этапе создают довольно тесную связь между структурой данных и их визуальным представлением.
Не верю (c). Мне трудно обсуждать некие неизвестные продукты, но я совершенно уверен, что толковые средства, примененные с участием мозгов, позволяют добиться хорошего результата.

Пусть будет Oracle Forms или Delphi и лень - "я за 1 час набросаю рабочее приложение и займусь следующим".

softwarerСобственно, представьте себе, что у Вас в СУБД выполняются:

Код: plaintext
1.
2.
3.
select * from Country
select * from Region
select * from City
select * from Hierarchical_Geo_Dictionary

Будьте так любезны, скажите пожалуйста, что из названного - таблицы, что - представления, и с чьей именно структурой данных намертво связано визуальное представление в "средствах разработки класса Builder"?

Сказать что связь "мёртвая" нельзя, но на развязку будут затрачены дополнительные ресурсы. В самом незатейливом случае, я перетаскиваю на форму таблицу Country и сдаю работу. Чем лучше метаданные таблицы отвечают требованиям GUI, тем меньше работы от меня требуется, тем скорее мы получим готовую систему без дефектов. В свою очередь архитектор БД может пойти мне на встречу, единообразно описать словари, дать полям человеческие названия, создать подходящие индексы и т.д.

softwarer
mcureenabПроектируя части системы с этим фактом нельзя не считаться. Если встречное движение архитектора БД и дизайнера UI позволяет создать сбалансированное решение, то почему бы не делать так?
Потому что оно будет не "сбалансированным", а "сильно связанным как раз в том месте, где этого не следует делать".

...

Код: plaintext
1.
- Почему втрое упала скорость ночного job-а, занимающегося экспортом (импортом, обсчетом,...) данных из вашей базы в нашу?
- Потому что мы изменили внешний вид нашего GUI-клиента, которого вы в глаза не видели.


Это как раз пример несбалансированного решения. Ложась костьми на ниве независимости БД и GUI мы создаём такие условия, что любое изменение БД требует офигенных затрат, на доработку могучего промежуточного слоя, вместо скромной доработки нескольких простых приложений. В данном случае я говорю не о трёхзвенной архитектуре, где промежуточный слой является неотъемлимой частью системы и в свою очередь создаётся из готовых блоков, а о старом добром клиент-сервере. Вообще, мы тут вышли в область конфигурационного управления. Являясь мостом, БД и СУБД должна так или иначе учитывать требования всех клиентов. В одном случае ускоряя GUI приложения на 1сек, мы можем пожертвовать несколькими часами работы низкоприоритетного фонового процесса, и т.д.

softwarer mcureenabИначе каждый будет горд своим гениальным и абсолютно правильным решением, а система в целом никогда не заработает.
Если разработчики системы потентны на уровне "а еще я в нее ем" - то начинать следует вовсе не со структуры данных.

Однозначно!
...
Рейтинг: 0 / 0
28.05.2007, 20:48
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556464
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
softwarer mcureenabЕсли коротко - моя твоя не понимай.
Моя говорит в общем стандартную вещь - конструкция двигателя автомобиля не должна зависеть от цвета его кузова, равно как и наоборот. Если я - пользователь - говорю "хорошая машина, все замечательно, вот только сделайте мне две дверцы вместо четырех" - инженеры не должны "заодно" менять инжектор на дизель.

"Как хранить данные" и "как отобразить данные" - два разных вопроса, в поиске ответа на который рассматриваются принципиально разные факторы. Допустим, у нас есть логические понятия "Страна", "Регион" и "Город" - кажется, мы начинали именно с них. В этом случае "архитектор БД" будет решать, делать ли три справочника либо один иерархический. А "дизайнер UI" будет решать, как делать выбор города - трехуровневым деревом или, допустим, тремя комбобоксами. Между ответами на эти вопросы нет и не может быть прямой связи (косвенно они, конечно, связаны через общую задачу и общий фрагмент модели). Как простая иллюстрация к отсутствию прямой связи - если клиент скажет "не хочу дерево, хочу комбобоксы" - никто не должен бежать к архитектору БД с криком "режь свою иерархическую таблицу натрое".

Вся это галиматье появилось от бедности (технической и алгоритмической). Какие-то архитекторы БД и т.д. :(
Что бы выкинуть всех этих архитекторов в свалку нужно только одно -
а) РБД сущность не таблица а набор одноименных таблиц в виде Таблица(Таблица_1(ид, свойство)...Таблица_n(ид,свойство)).
б) В ООП вместо отдельных свойств и методов ввести коллекцию свойств и коллекцию методов.

Все должны работать на пользователя, а на какие-то принципы. Если пользователю не нравится двигатель, то в течении 14 дней надо предложить либо то, что его устраивает, либо деньги на бочку и возможно с процентами. :)
Блин, каждую вынужденную туфту превращают в догму. :(
Идеальный случай хранения данных - фотография + измерение параметров окружения записанная на ней же.
...
Рейтинг: 0 / 0
28.05.2007, 22:49
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556476
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenabС++ Builder, Delphi, Oracle Forms.
Из этих средств я хорошо знаю одно и имею неплохое представление о другом. Будьте так любезны, не рассказывайте о них сказки.

mcureenabВ идеале, для строительства приложения не требуется писать ни одной строчки кода.
Верю. И это позволяет строить нормальные по архитектуре приложения. Про Oracle Forms ничего сказать не могу, но если они так не могут - это исключительно их проблемы.

mcureenabи лень - "я за 1 час набросаю рабочее приложение и займусь следующим".
Угу. "Продам его, получу деньги, забуду все контакты этого клиента, не буду отвечать на его письма-звонки, а буду заниматься тем, чтобы пытаться впарить следующее приложение следующему клиенту".

Не зря говорят, что программисту полезно поработать над сопровождением ПО. После того, как поразгребаешь своего (или чужого) дерьма, взгляды на жизнь и на "приложение за час" несколько корректируются. После этого нужно отстрелять тех, кто приходит к выводу "все в мире дерьмо", а с оставшимися можно иметь дело.

mcureenabСказать что связь "мёртвая" нельзя, но на развязку будут затрачены дополнительные ресурсы.
Нее, Вы таки пожалуйста скажите. После чего окажется, что "архитектор БД" может (ради решения своих задач) перекособочить эту "мертвую связь" в хвост и в гриву, и приложение этого не заметит.

mcureenabВ самом незатейливом случае, я перетаскиваю на форму таблицу Country и сдаю работу.
А кто Вам сказал, что это таблица? Перетащили? Хорошо. Сдали работу? Хорошо. После чего я меняю только БД, и угадайте с трех раз - будет Ваш exe-шник работать со вьюхой Country или нет?

mcureenabЭто как раз пример несбалансированного решения.
То есть Вы признаете, что Ваш путь соответствия ведет к несбалансированному решению? Замечательно, давайте тогда вернемся к тому месту, где Вы объявили такое решение сбалансированным, и попробуйте дать какой-нибудь другой ответ в том месте.

mcureenabЛожась костьми на ниве независимости БД и GUI мы создаём такие условия, что любое изменение БД требует офигенных затрат
Совершенно безосновательное утверждение.

mcureenab, на доработку могучего промежуточного слоя,
C этого момента Вы уходите в какие-то собственные фантазии, никак не связанные со сказанным мной.

mcureenabвместо скромной доработки нескольких простых приложений.
Угу. Я имел возможность оценить эту скромную доработку. Сам я, слава мне, никогда не доходил до такого маразма, но однажды меня попросили со старой работы подхалтурить на выходных, и я имел возможность оценить прелесть этого подхода в их новом проекте. Для решения практически любой мелкой задачи - уровня "вот сюда вывести пару дополнительных колонок" - приходится разрываться между сервером и клиентом. Производительность труда падает просто катастрофически.

mcureenabВ данном случае я говорю не о трёхзвенной архитектуре, где промежуточный слой является неотъемлимой частью системы и в свою очередь создаётся из готовых блоков, а о старом добром клиент-сервере.
А в чем разница? Почему в трехзвенке он "создается из готовых блоков", а в КС нет? Вы это про Oracle Forms?

mcureenabВообще, мы тут вышли в область конфигурационного управления.
Именно так. И постулируя какие-либо жесткие, однозначные связи, мы сами себя лишаем возможности управлять.

mcureenabЯвляясь мостом, БД и СУБД должна так или иначе учитывать требования всех клиентов. В одном случае ускоряя GUI приложения на 1сек, мы можем пожертвовать несколькими часами работы низкоприоритетного фонового процесса, и т.д.
Именно так. Это одна из причин, из-за которых связь между "кирпичиками" клиента и сервера вовсе не один к одному.
...
Рейтинг: 0 / 0
28.05.2007, 23:03
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556480
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Сахават Юсифова) РБД сущность не таблица а набор одноименных таблиц в виде Таблица(Таблица_1(ид, свойство)...Таблица_n(ид,свойство)).
б) В ООП вместо отдельных свойств и методов ввести коллекцию свойств и коллекцию методов.
"Ни хрена не понял, но скажу какую-нибудь чушь". Не ожидал, что сообщение коллеги Бреда приведет к столь.. занимательным результатам.
...
Рейтинг: 0 / 0
28.05.2007, 23:09
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556485
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
softwarer Сахават Юсифова) РБД сущность не таблица а набор одноименных таблиц в виде Таблица(Таблица_1(ид, свойство)...Таблица_n(ид,свойство)).
б) В ООП вместо отдельных свойств и методов ввести коллекцию свойств и коллекцию методов.
"Ни хрена не понял, но скажу какую-нибудь чушь". Не ожидал, что сообщение коллеги Бреда приведет к столь.. занимательным результатам.
Да бросьте. Нечего ограничения инструмента возводить в ранг истины. Ну не могут какие-то РБД и т.д. жить без архитекторов БД, которые ничего не смысля в предметней области (спросили того, спросили этого - методика проектирования) строят "нормализованные" БД. То Дейт так сказал, то Кейт то написал.
Смотрите форум. Как тольуо люди начали уходить от бухгалтерских задач, только и слышно - а как такую БД сделать, щоб потом не ковырятся? Этот вопрос изодня в день мучает народ. А Вы ту вешаете - на каждый конкретный случай можно придумать РБД! Фига с два.
...
Рейтинг: 0 / 0
28.05.2007, 23:28
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556495
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Сахават ЮсифовДа бросьте.
Это для меня нехарактерно. Я, если Вы еще не заметили, жуткий зануда.

Простите за нескромный вопрос, Вы уверены, что с той стороны логина - именно Вы и примерно в том же состоянии, в котором обычно пишете в форум?
...
Рейтинг: 0 / 0
28.05.2007, 23:45
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556538
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Ишь, куда вас понесло... Сейчас мы тихий-мирный топик превратим в очередную арену сражений сторонников различных концептуальных подходов.
Подписываюсь под словами softwarer'а. Вот был я ну совсем тупой и ляпнул:
"Могу сказать, что из этих отдельных таблиц можно сотворить поля со списками с динамическим обновлением (научили как), а также строить всякие запросы. Дерево займет много места на форме (по сравнению с 3 ComboBox'ами), да и не научился я пока с деревьями работать."
Теперь чуть умнее стал и теперь мне все равно - деревом или 3 (4, 5,...) комбобоксами. Теперь я буду смотреть как мне таблицы логичнее сделать, а не как бы их под удобный интерфейс подстроить.

2 mcureenab
>Одно дело - наши желания, другое - наши возможности. Если дизтопливо оставляет пятна на краске, то нужно либо бензиновый двигатель ставить, либо краску менять и т.п..
Нет, имхо, двигатель для машины более важная деталь, чем тип краски. Если человек выбирает двигатель по критерию оставляет ли соответствующее топливо пятна на краске... Ну это как если бы я выбрал в качестве СУБД FoxPro 2.6 потому, что там есть пятнашки и можно поиграть, если мозги закипели.

Что-то не туда нас понесло. К делу.
В одном из предыдущих постов я, кажется, соврал: "Насколько я знаю, в MapInfo нет ключей объектов."
Вот кусок ответа Denis Popov из топика "Хранение картографической информации" (на этом же форуме):
"Т.е. вся "картинка", статика, находится не в БД, а в БД не хранится геоинформация, только привязка идентификаторов объектов MapInfo к данным."
Так что, кажется, есть у объектов MapInfo "ключи". Можно попробовать. Значит, получается, в базе можно хранить идентификаторы объектов MapInfo, но обновлять их ручками или писать навороченную процедуру проверки таблиц MapInfo, проверки всех объектов (в т.ч. и созданных) во всех слоях, сливания полученных значений идентификаторов в таблицу БД? Не могу объяснить, но предчувствую какие-то грабли при таком подходе. Хотя с другой стороны, выгружаем же мы в MapInfo таблицы из БД – и ничего.

2 mcureenab
>Могу предположить, что картографические объекты проще и эффективнее хранить в виде BLOB в формате, который непосредственно воспринимает MapInfo.
Что же мне теперь - на SQL Server переходить? Из того, что более-менее мне доступно, BLOB'ы есть только там.

>По координатам точки найти район, в котором эта точка находится. В этом случае выгружаем в MapInfo карту районов, и запрашиваем у него id района в котором находится данная точка. MapInfo наверняка такие функции имеет.
Вот видите, еще недавно вы утверждали абстрактность понятия точки, а контексте текущей задачи оно очень даже пригодилось. Повторюсь, тут вот в чем закавыка – не знаем мы координаты точки! Написал автор "в пойменных лесах среднего течения Дона". Карту какого района выводить? Среднее течение Дона – это не в одном районе, и даже не в одной области. Только если я отрисую в слоях все объекты и буду знать их идентификаторы - тогда см. предыдущий абзац.

З.Ы. Пока я на работе пишу ответы на предыдущие посты - тут уже столько успевают за день понаписать, что мне приходится дописывать в 2 раза больше.
...
Рейтинг: 0 / 0
29.05.2007, 00:32
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556602
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tchingizПривилегированный пользователь
Участник
Бред tchingiz Бред softwarer
Первое и самое главное. Запомните это, распечатайте, повесьте на стену и ежедневно проверяйте, пока не прочувствуете на подсознательном уровне:

Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот

Увязывать их - одна из самых больших глупостей, которые могут быть сделаны проектировщиком.

Весьма не профессиональное высказывание. Удружил "начинающему".
Вы намекаете что структуры данных должны зависеть от пользовательского интрефейса
и это, якобы удешевит проект, продукт и весь жизненный цикл?

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

отрицание фразы
(Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот) ==
структура данных в БД должна зависеть от пользовательского интерфейса программи
или пользовательский интерфейс должен зависеть, от структуры данных БД.
/*
Заметьте, Вы, в ходе беседы, как то плавно "структуру данных БД" заменили на "концептуальную модель". Считается, что такая подмена корректна?
*/


Более того, я и сейчас, после уточнения струдом понимаю,
какэто пользовательский интерфейс должен зависеть от структуры данных БД.

Это чтоли на реляционной БД должен быть один интерфейс,
а на иерархической - другой?


Я то грешным делом думал, что ГУИ надо писать по возможности независимым.
...
Рейтинг: 0 / 0
29.05.2007, 03:49
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34556961
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer mcureenabЕсли коротко - моя твоя не понимай.
Моя говорит в общем стандартную вещь - конструкция двигателя автомобиля не должна зависеть от цвета его кузова, равно как и наоборот. Если я - пользователь - говорю "хорошая машина, все замечательно, вот только сделайте мне две дверцы вместо четырех" - инженеры не должны "заодно" менять инжектор на дизель.

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


softwarer"Как хранить данные" и "как отобразить данные" - два разных вопроса, в поиске ответа на который рассматриваются принципиально разные факторы.

это очень взаимосвязано. Особенно в последнее время, в связи с повышением пользовательского приоритета в сторону интерфейсов.

softwarerМежду ответами на эти вопросы нет и не может быть прямой связи (косвенно они, конечно, связаны через общую задачу и общий фрагмент модели). Как простая иллюстрация к отсутствию прямой связи - если клиент скажет "не хочу дерево, хочу комбобоксы" - никто не должен бежать к архитектору БД с криком "режь свою иерархическую таблицу натрое".
конечно же есть связь :) Попытки постоить какие-либо интерфейсы на неподходящей для них структуре данных выглядят ужасно.
...
Рейтинг: 0 / 0
29.05.2007, 10:16
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34557028
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
КДТеперь я буду смотреть как мне таблицы логичнее сделать, а не как бы их под удобный интерфейс подстроить.

Пользователям тоже так отвечаете на вопросы, почему чтобы сделать простую операцию нужно так извратиться? Зато какие таблицы логичные. :) Интерфейс и структура данных - неразрывны. А в последнее время - тем более. Идет борьба интерфейсов.
...
Рейтинг: 0 / 0
29.05.2007, 10:36
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34557083
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmможет не совсем в таком виде, но зависимость конечно же есть . Если в первую очередь рождается кузов (интерфейс), как концепт. Под него и движок подбирается.
С моей точки зрения "в первую очередь рождается идея, а уж потом под нее подбираются кузов, движок и все остальное". Если размышлять в терминах "сначала рождается кузов" - то есть классический восходящий подход - то есть ровно два варианта: либо на самом деле проектировщик таки видит в голове общую картину, просто сосредоточился на одной из нижних деталей, либо же имеем все прелести восходящего подхода, которые вчера описывал коллега mcureenab - "каждый сделал свое, теперь думаем, как же это состыковать".

Связь тут конечно есть, но связь, а не зависимость. Разница между этими понятиями - примерно как между понятиями "родственник" и "потомок".

iscrafm softwarer"Как хранить данные" и "как отобразить данные" - два разных вопроса, в поиске ответа на который рассматриваются принципиально разные факторы.

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

Как простой пример в общей для нас области - есть пример "убогого фреймворка" - компонент TTable. Если попытаться применить его к нетривиальной задаче - действительно окажется, что либо мы один в один отображаем структуру данных сервера, либо тратим кучу усилий, а результат еще хуже. Стоит начать использовать менее убогий TQuery - и жесткая зависимость пропадает. Также жесткая зависимость пропадает, если на сервере используем вьюху или хранимку.
...
Рейтинг: 0 / 0
29.05.2007, 10:50
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34557093
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmПользователям тоже так отвечаете на вопросы, почему чтобы сделать простую операцию нужно так извратиться?
Не стоит приписывать другим одноклеточное мышление.

iscrafmИнтерфейс и структура данных - неразрывны.
Тогда понятно, почему ваш фреймворк никого кроме вас не интересует.
...
Рейтинг: 0 / 0
29.05.2007, 10:53
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34557111
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
softwarer Сахават ЮсифовДа бросьте.
Это для меня нехарактерно. Я, если Вы еще не заметили, жуткий зануда.

Простите за нескромный вопрос, Вы уверены, что с той стороны логина - именно Вы и примерно в том же состоянии, в котором обычно пишете в форум?

Состояние было перегретым, не не настолько.
Я собственно имел ввиду только один вопрос - как дать возможность пользователю находу, безболезненно менять структуру РБД (собственно говоря ввести новые свойства для НЕКОТОРЫХ объектов) с автоматическим отражением в пользовательском интерфейсе.

Тут три подхода.
1. Добавить новое свойство в существующую таблицу. (ALTER)
2. EAV.
3. Ввести новое свойство (набор), как новую таблицу связанную с основной один<->один.
Т.е., каждая таблица = множество таблиц с одним или несколько своствами + таблица описания спецификаций (из каких таблиц состоят таблицы).

Поразмыслив над + и - всех трех (а может и еще какие есть) вариантов, остановился на 3.
Про это так громко сказал. (Вещь то тривиальная, но требует переопределение select, insert, update, delete. Как - это другой вопрос)
...
Рейтинг: 0 / 0
29.05.2007, 10:57
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34557113
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer
Как простой пример в общей для нас области - есть пример "убогого фреймворка" - компонент TTable. Если попытаться применить его к нетривиальной задаче - действительно окажется, что либо мы один в один отображаем структуру данных сервера, либо тратим кучу усилий, а результат еще хуже. Стоит начать использовать менее убогий TQuery - и жесткая зависимость пропадает. Также жесткая зависимость пропадает, если на сервере используем вьюху или хранимку.
Вы привели пример замены интерфейса. TTable, TQuery - это интерфейсы . Если нужен именно TTable... Естественно Вы задумаетесь как спроектировать структуру данных, чтобы система нормально работала с требуемым интерфейсом. Т.е. "убогость" какого-то там фреймворка здесь не причем.
...
Рейтинг: 0 / 0
29.05.2007, 10:58
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34557132
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer iscrafmПользователям тоже так отвечаете на вопросы, почему чтобы сделать простую операцию нужно так извратиться?
Не стоит приписывать другим одноклеточное мышление.

А Вы как отвечаете? Вы системы с интерфейсами строите?

softwarer iscrafmИнтерфейс и структура данных - неразрывны.
Тогда понятно, почему ваш фреймворк никого кроме вас не интересует.
что за бред, перегрелись? Если Вы до него не доросли, то не стоит судить по себе о других. К тому же тема совсем другая.
...
Рейтинг: 0 / 0
29.05.2007, 11:02
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34557152
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
iscrafm softwarer iscrafmПользователям тоже так отвечаете на вопросы, почему чтобы сделать простую операцию нужно так извратиться?
Не стоит приписывать другим одноклеточное мышление.

А Вы как отвечаете? Вы системы с интерфейсами строите?

softwarer iscrafmИнтерфейс и структура данных - неразрывны.
Тогда понятно, почему ваш фреймворк никого кроме вас не интересует.
что за бред, перегрелись? Если Вы до него не доросли, то не стоит судить по себе о других. К тому же тема совсем другая.

Просто, наверное, определенная часть контингента не занималась практическими делами, а только теоретизирует.
...
Рейтинг: 0 / 0
29.05.2007, 11:07
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34557374
Prince-1777
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Prince-1777
Гость
Я думаю, что структура БД сама по себе нафик никакому заказчику не интересна.
Рассмотрим БД как черный ящик, к которому подключено:

1) Пользовательский интерфейс для ввода и просмотра информации "по записям". Короче - ввод первичных документов.

2) Различная отчетность, от первички до OLAP.

3) API промежуточных итогов (могут являться исходными данными для других расчетов) - то есть требование к мгновенности получения.

4) Системы пакетной загрузки / выгрузки данных (например биллинг, синхронизация, консолидация).

Разные пункты диктуют разную структуру БД, и на деле всегда получается компромис. Задача грамотного архитектора - минимизировать число внутренних трансформаций данных. Потому как любая трансформация - это код, а значит ошибки и стоимость поддержки. Остальные аргументы - религия.

Так что совпадение интерфейса и структуры БД - это только плюс, при условии, что остальные пункты не страдают :)
...
Рейтинг: 0 / 0
29.05.2007, 11:59
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558031
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
КДТак что, кажется, есть у объектов MapInfo "ключи". Можно попробовать. Значит, получается, в базе можно хранить идентификаторы объектов MapInfo, но обновлять их ручками или писать навороченную процедуру проверки таблиц MapInfo, проверки всех объектов (в т.ч. и созданных) во всех слоях, сливания полученных значений идентификаторов в таблицу БД? Не могу объяснить, но предчувствую какие-то грабли при таком подходе. Хотя с другой стороны, выгружаем же мы в MapInfo таблицы из БД – и ничего.

ИМХО, тебе надо получше познакомиться с инструментом, который собираешься использовать, тогда и вопросы многие отпадут.

КД2 mcureenab
>Могу предположить, что картографические объекты проще и эффективнее хранить в виде BLOB в формате, который непосредственно воспринимает MapInfo.
Что же мне теперь - на SQL Server переходить? Из того, что более-менее мне доступно, BLOB'ы есть только там.

Сегодня на канале ВЕСТИ рассказывали как американские чуваки в супермаркеты ходят. Если чувак не нашёл нужный ему товар, то он лучше не купит ничего, чем будет искать аналог...

Ну нету типа с именем BLOB, есть другие достаточно ёмкие типы. Наконец двоичные данные можно просто во внешних файлах хранить даже не привязывая их к БД.


КД>По координатам точки найти район, в котором эта точка находится. В этом случае выгружаем в MapInfo карту районов, и запрашиваем у него id района в котором находится данная точка. MapInfo наверняка такие функции имеет.
Вот видите, еще недавно вы утверждали абстрактность понятия точки, а контексте текущей задачи оно очень даже пригодилось. Повторюсь, тут вот в чем закавыка – не знаем мы координаты точки! Написал автор "в пойменных лесах среднего течения Дона". Карту какого района выводить? Среднее течение Дона – это не в одном районе, и даже не в одной области. Только если я отрисую в слоях все объекты и буду знать их идентификаторы - тогда см. предыдущий абзац.

Придумай алгоритм. Я так понимаю, если есть понятие "Пойменный лес среднего течения Дона", то в картографической подсистеме должны быть объекты, которые обозначают эту территорию на карте, а раз так, то можно найти карты где эта территория обозначена или даже создать новую карту покрытия этой территории интересующими нас объектами. Например, можно взять карту плотности расселения мышей полёвок, выделить на ней регион "Пойменный лес среднего течения Дона" и получить карту совместного проживания змей и мышей.
Т.е. изначально в системе не прописана организация географических объектов из предметной области приложения. В зависимости от решаемой задачи мы находим множество объектов с общими геометрическими свойствами и выводим их на карте. Полученный результат мы можем сохранить в виде карты, или другого структурированного описания, но можем каждый раз вычислять заново учитывая новые сведения.

Если в картографической системе нет понятия "Пойменный лес среднего течения Дона", то описание не формализовано в картографических терминах. В этом случае нужно описать регион в картографической подсистеме. После этого работа сведётся к операциаям над геометрическими фигурами.
...
Рейтинг: 0 / 0
29.05.2007, 14:43
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558197
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
softwarer mcureenabВ самом незатейливом случае, я перетаскиваю на форму таблицу Country и сдаю работу.
А кто Вам сказал, что это таблица? Перетащили? Хорошо. Сдали работу? Хорошо. После чего я меняю только БД, и угадайте с трех раз - будет Ваш exe-шник работать со вьюхой Country или нет?


Ну я так не играю!..

Из контекста я полагал, что Country это всё же таблица, а не представление. А подмена таблицы представлением или даже синонимом операция далеко не безобидная, не прозрачная для приложения. Это у математиков всё есть реляционное отношение, а в реализации мы имеем дело не с абстрактными отношениями, а с конкретными таблицами, запросами, представлениями, вычисляемыми полями, индексами, планами и т.д. и т.п. со своими особенностями, капризами и закидонами.
Даже замена СУБД как правило требует доработок в логике системы.

Ну ладно. Я думаю, со временем мы получим мощные инструметны и архитектуры позволяющие полностью абстрагировать GUI и бизнес логику от структуры данных. Уже сейчас объектные технологии позволяют инкапсулировать подробности реализации внутри объекта или компонента. Кто то использует их, кто то работает по старинке.
...
Рейтинг: 0 / 0
29.05.2007, 15:14
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558405
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Сахават ЮсифовЯ собственно имел ввиду только один вопрос - как дать возможность пользователю находу, безболезненно менять структуру РБД
Сахават, согласитесь, что это отдельная большая тема, которую можно и интересно обсудить, но не стоит делать этого в топике, посвященного другому вопросу.

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

Лично я в такой задаче использовал первый подход, но выбор имхо зависит от контекста - легко назвать ситуации, в которых предпочтительно то или иное решение.
...
Рейтинг: 0 / 0
29.05.2007, 16:01
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558471
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmВы привели пример замены интерфейса. TTable, TQuery - это интерфейсы .
Ну если Вам угодно использовать именно такой термин, почему бы и нет? Но я бы просил больше думать о сути.

iscrafmЕсли нужен именно TTable... Естественно Вы задумаетесь как спроектировать структуру данных, чтобы система нормально работала с требуемым интерфейсом. Т.е. "убогость" какого-то там фреймворка здесь не причем.
Ровно наоборот. "Убогость фреймворка TTable" вызывает необходимость "проектировать структуру данных с учетом его убогости". Напротив, "неубогий фреймворк TQuery" убирает зависимость структуры данных и интерфейса, позволяя сделать гибкую развязку между ними. Разумеется, ее можно делать и другими способами, например, как я называл выше, через view (отметим - view не относится к "структуре данных").

iscrafmА Вы как отвечаете?
Если предположить, что я где-то "плохо отвечал" - это причина высказать претензию мне. Желательно, предметную - с указанием, какие именно фразы чем именно недопустимы. И совершенно не причина приписывать хрен знает какую глупость коллеге КД .

iscrafmчто за бред, перегрелись? Если Вы до него не доросли,
Если я не дорос, это мелочь. А если вспомнить, какой бурный энтузиазм ваше решение вызывало во всех темах, где Вы его рекламировали - это уже тенденция.

iscrafmК тому же тема совсем другая.
Cогласен, другая. Давайте оставим ее, и Вы попытаетесь найти какие-либо объективные аргументы в поддержку своего тезиса о тесной связи структуры и интерфейса. Пока он голословен (аргументирован двумя-тремя утверждениями класса "ссылка на личный опыт", который "другая тема").
...
Рейтинг: 0 / 0
29.05.2007, 16:13
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558520
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenabНу я так не играю!..

Из контекста я полагал, что Country это всё же таблица
Стоп-стоп-стоп. Я начал с того, что привел Вам объекты и попросил назвать - что их них таблицы, что представления. Вы эту просьбу не выполнили, а теперь вдруг что-то "полагали".......

mcureenabА подмена таблицы представлением или даже синонимом операция далеко не безобидная, не прозрачная для приложения.
Не безобидная, но прозрачная для приложения. Ее "обидность" лечится все на том же сервере.

В том, что касается физики, безусловно согласен, но тем не менее, подобные операции достаточно часто нужны и достаточно часто выполняются - это уже статистика ответов по форумам.

mcureenabДаже замена СУБД как правило требует доработок в логике системы.
Даже

"Замена СУБД" - вещь на порядки более капитальная по последствиям, нежели названная подмена.

mcureenabЯ думаю, со временем мы получим мощные инструметны и архитектуры позволяющие полностью абстрагировать GUI и бизнес логику от структуры данных.
Подходящие инструменты существуют давным-давно, объектные технологии тут совершенно не при чем, как впрочем и во всех других архитектурных вопросах. Вопрос исключительно в том, какие принципы закладываются в реализацию. Утрированно - если Вы используете только запросы вида select * from Table, значит задачу вида "показать эти данные вместе" Вы сможете решить только сведя их в одну таблицу. Если Вы готовы пойти на использование join - Вы уже свободны в выборе, связь теряет жесткость.
...
Рейтинг: 0 / 0
29.05.2007, 16:22
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558645
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer"неубогий фреймворк TQuery" убирает зависимость структуры данных и интерфейса, позволяя сделать гибкую развязку между ними. Разумеется, ее можно делать и другими способами, например, как я называл выше, через view
:)


softwarer
iscrafmА Вы как отвечаете?
Если предположить, что я где-то "плохо отвечал" - это причина высказать претензию мне. Желательно, предметную - с указанием, какие именно фразы чем именно недопустимы. И совершенно не причина приписывать хрен знает какую глупость коллеге КД .
Вы о чем? я вроде ничего коллеге КД не приписывал, кроме его собственных слов.

softwarer
iscrafmчто за бред, перегрелись? Если Вы до него не доросли,
Если я не дорос, это мелочь. А если вспомнить, какой бурный энтузиазм ваше решение вызывало во всех темах, где Вы его рекламировали - это уже тенденция.

Вы хоть подскажите, где я рекламой занимаюсь, а то я и не знаю :) Хотя в чем-то Вы правы. Я имею ввиду энтузиазм, который я измеряю в лицензиях и реализованных проектах. Внешними разработчиками конечно.

softwarer
iscrafmК тому же тема совсем другая.
Cогласен, другая. Давайте оставим ее, и Вы попытаетесь найти какие-либо объективные аргументы в поддержку своего тезиса о тесной связи структуры и интерфейса. Пока он голословен (аргументирован двумя-тремя утверждениями класса "ссылка на личный опыт", который "другая тема").
Оставим и это тоже. Одно дело раскрывать очевидные вещи на лекциях студентам, другое - мусолить их на форуме, где в общем-то состоявшиеся разработчики присутствуют. Если Вы проектируете интерфейс системы и структуру баз данных, которые она использует, независимо друг от друга, то это Ваше личное дело. Успехов. У меня под требуемый интерфейс проектируется соответствующая структура. Данные в отрыве от интерфейсов не живут, с ними работают люди.
...
Рейтинг: 0 / 0
29.05.2007, 16:44
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558686
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
Сахават Юсифовкак дать возможность пользователю находу, безболезненно менять структуру РБД
Элементарно - вводим метауровень, пользователь видит и меняет только его, метауровень автоматом отображается на РБД.
...
Рейтинг: 0 / 0
29.05.2007, 16:49
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558725
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Элементарно

Погорячились.

> вводим метауровень

Нотация?

> пользователь видит и меняет только его

Откуда желание дать пользователю вообще что-то менять? Зачем? Ничего полезного юзер своими кривыми ручонками в принципе сделать не может.

> метауровень автоматом отображается на РБД

И полУчите в результате огромную кучу дерьма, которую базой данных в принципе нельзя будет назвать.
...
Рейтинг: 0 / 0
29.05.2007, 16:57
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558736
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
softwarer Сахават ЮсифовЯ собственно имел ввиду только один вопрос - как дать возможность пользователю находу, безболезненно менять структуру РБД
Сахават, согласитесь, что это отдельная большая тема, которую можно и интересно обсудить, но не стоит делать этого в топике, посвященного другому вопросу.


Согласен. Надо один раз показать универсальную альтернативу для EAV обладающей ее плюсами, но без ее недостатков. Думаю, что п 3. является хорошей альтернативой.
А там, пусть делают как хотят. Я ж не для себя. :(
...
Рейтинг: 0 / 0
29.05.2007, 16:59
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558766
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmВы о чем? я вроде ничего коллеге КД не приписывал, кроме его собственных слов.
Не путайте пожалуйста "его собственные слова" с "объективным бредом, который Вы, возможно, искренне полагаете смыслом его собственных слов".

iscrafmВы хоть подскажите, где я рекламой занимаюсь,
Занимались, года два назад. Примерно так же, как допустим приснопамятный Alex Rovdo всюду совал свой Versant.

iscrafmХотя в чем-то Вы правы. Я имею ввиду энтузиазм, который я измеряю в лицензиях и реализованных проектах. Внешними разработчиками конечно.
Это, к сожалению, трудно оценить со стороны с приемлимой трудоемкостью.

iscrafmОставим и это тоже.
OK.

iscrafmОдно дело раскрывать очевидные вещи на лекциях студентам, другое - мусолить их на форуме, где в общем-то состоявшиеся разработчики присутствуют.
Хм. Любопытно, в чем именно сложность - то ли "состоявшиеся разработчики тупее студентов", то ли "вещи оказываются вовсе не очевидными".....
...
Рейтинг: 0 / 0
29.05.2007, 17:07
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558773
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
модЭлементарно - вводим метауровень, пользователь видит и меняет только его, метауровень автоматом отображается на РБД.
Есть общеизвестный пример реализации подобного подхода, называется 1С.
...
Рейтинг: 0 / 0
29.05.2007, 17:08
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558817
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Есть общеизвестный пример реализации подобного подхода, называется 1С

Кроме кривых поделок Вы действительно больше ничего не видели?
...
Рейтинг: 0 / 0
29.05.2007, 17:17
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558827
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
softwarer mcureenabНу я так не играю!..

Из контекста я полагал, что Country это всё же таблица
Стоп-стоп-стоп. Я начал с того, что привел Вам объекты и попросил назвать - что их них таблицы, что представления. Вы эту просьбу не выполнили, а теперь вдруг что-то "полагали".......


Ах вот Вы о чём... Относительно оператора select таблицы и представления формально (в частности на этапе компиляции) неразличимы. Но как только дело доходит до выполнения всплывает всё.
Если идентификатор отношения БД использовать для изменения данных, то разница между таблицей и представлением тут же проявляется и я не видел способа её полнолностью скрыть.
...
Рейтинг: 0 / 0
29.05.2007, 17:18
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558978
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarerНе путайте пожалуйста "его собственные слова" с "объективным бредом, который Вы, возможно, искренне полагаете смыслом его собственных слов".
чтобы Вас в сторону не несло, я процитирую
КДТеперь я буду смотреть как мне таблицы логичнее сделать, а не как бы их под удобный интерфейс подстроить.
Вы о чем?


softwarer
iscrafmВы хоть подскажите, где я рекламой занимаюсь,
Занимались, года два назад. Примерно так же, как допустим приснопамятный Alex Rovdo всюду совал свой Versant.
Покажите, если так осведомлены, а то не понятно о чем Вы.

softwarer
iscrafmОдно дело раскрывать очевидные вещи на лекциях студентам, другое - мусолить их на форуме, где в общем-то состоявшиеся разработчики присутствуют.
Хм. Любопытно, в чем именно сложность - то ли "состоявшиеся разработчики тупее студентов", то ли "вещи оказываются вовсе не очевидными".....
просто неприлично взрослым людям объяснять, что твердую пищу (данные) тяжело засунуть в тюбик из под зубной пасты (интерфейс).
...
Рейтинг: 0 / 0
29.05.2007, 17:49
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558984
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
guest_20040621> Есть общеизвестный пример реализации подобного подхода, называется 1С

Кроме кривых поделок Вы действительно больше ничего не видели?
Видел. Я кстати не озвучил характеристику указанного варианта реализации.
...
Рейтинг: 0 / 0
29.05.2007, 17:50
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34558993
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
iscrafm guest_20040621> Есть общеизвестный пример реализации подобного подхода, называется 1С

Кроме кривых поделок Вы действительно больше ничего не видели?
Видел. Я кстати не озвучил характеристику указанного варианта реализации.
Блин, ну очем спор?
Если вещь самодостаточно, то ее делат под интерфейс.
Если ты не знаешь всю систему, то интерфейс делается с учетом БД (или БД создает представление для этого интерфеса).
...
Рейтинг: 0 / 0
29.05.2007, 17:53
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559053
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenabАх вот Вы о чём... Относительно оператора select таблицы и представления формально (в частности на этапе компиляции) неразличимы. Но как только дело доходит до выполнения всплывает всё.
Да и не только относительно select. О чем я.... я о том, что утверждение наличие некоторой "жесткой связи" для "средств класса Builder", или как там они были названы, попадает в цугцванг уже на таком элементарном примере. Что бы Вы ни назвали таблицами, я могу с противным смешком сказать, что на самом деле все строго наоборот, и это вьюха, а таблица - "другой объект".

В данном случае это сугубо формальный пример, иллюстрирующий, что жесткая связь существует исключительно в голове разработчика, не в инструменте.

А что именно "все всплывает", простите?
...
Рейтинг: 0 / 0
29.05.2007, 18:07
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559090
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
tchingiz Бред tchingiz Бред softwarer
Первое и самое главное. Запомните это, распечатайте, повесьте на стену и ежедневно проверяйте, пока не прочувствуете на подсознательном уровне:

Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот

Увязывать их - одна из самых больших глупостей, которые могут быть сделаны проектировщиком.

Весьма не профессиональное высказывание. Удружил "начинающему".
Вы намекаете что структуры данных должны зависеть от пользовательского интрефейса
и это, якобы удешевит проект, продукт и весь жизненный цикл?

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

отрицание фразы
(Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот) ==
структура данных в БД должна зависеть от пользовательского интерфейса программи
или пользовательский интерфейс должен зависеть, от структуры данных БД.
/*
Заметьте, Вы, в ходе беседы, как то плавно "структуру данных БД" заменили на "концептуальную модель". Считается, что такая подмена корректна?
*/


Более того, я и сейчас, после уточнения струдом понимаю,
какэто пользовательский интерфейс должен зависеть от структуры данных БД.

Это чтоли на реляционной БД должен быть один интерфейс,
а на иерархической - другой?


Я то грешным делом думал, что ГУИ надо писать по возможности независимым.

Ага, корректна. И не подмена вовсе, в связи с упоминанием про концептуальную и логическую модели. Вы одних в точности цитируете, а других как-то странно интерпретируете.
Реляционная и иерархическая - это разве не логические?
А вот в независимости ГУИ есть мощная логика, не противоречащая моим высказываниям. Написал ГУИ для метамодели и хорошо...
...
Рейтинг: 0 / 0
29.05.2007, 18:14
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559125
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
guest_20040621> Что же касается "зависимости структуры данных от интерфейса",
> то она тоже имеет место на уровне метамодели, так учат в университетах

Бросайте такие университеты. Ничему хорошему Вас там не научат.

Слушаюсь!
...
Рейтинг: 0 / 0
29.05.2007, 18:20
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559233
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Слушаюсь!

Напрасно ерничаете. Ведь так и будете продолжать считать, что нужно писать гуй для метамодели.

> Я кстати не озвучил характеристику указанного варианта реализации.

Вот как раз imho некстати не озвучили. :) С удовольствием бы послушал и обсудил.
...
Рейтинг: 0 / 0
29.05.2007, 18:51
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559243
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmчтобы Вас в сторону не несло, я процитирую
КДТеперь я буду смотреть как мне таблицы логичнее сделать, а не как бы их под удобный интерфейс подстроить.
Вы о чем?
О том, что Вы передернули эти слова в самопридуманные [эпитет опущен]

почему чтобы сделать простую операцию нужно так извратиться

Я понимаю, что Вы не понимаете сказанного и не хотите пытаться понять. Мы с Вами сейчас ровно в том же положении, в котором оказываются КС-программисты, пытающиеся объяснить "упертым однозвенщикам" преимущества КС; ровно в том же положении, в котором оказываются многозвенщики, пытающиеся объяснить "упертым КСовцам" преимущества многозвенки итп.

iscrafmПокажите, если так осведомлены, а то не понятно о чем Вы.
Частичто об упоминаниях типа http://sql.ru/forum/actualthread.aspx?tid=255147&pg=1&hl=, частично об... активности в более крупных обсуждениях, типа /topic/33967&pg=23#3352662

iscrafmпросто неприлично взрослым людям объяснять, что твердую пищу (данные) тяжело засунуть в тюбик из под зубной пасты (интерфейс).
Подумайте о том, что "тюбик из-под зубной пасты" неплохо подходит для столь разных структур, как "мягкая пища", "жидкая пища" и "газообразная пища".
...
Рейтинг: 0 / 0
29.05.2007, 18:54
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559273
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
guest_20040621> Слушаюсь!

Напрасно ерничаете. Ведь так и будете продолжать считать, что нужно писать гуй для метамодели.



Не переживайте. "Все уже написано. До нас" (С).
Так что уже не важно слушаться ли, ерничать ли, ...
...
Рейтинг: 0 / 0
29.05.2007, 19:04
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559357
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Не переживайте.

Спасибо, я так и делаю.

> "Все уже написано. До нас" (С)

Разве? По-моему, все самое интересное только начинается.

> Так что уже не важно слушаться ли, ерничать ли, ...

У меня совершенно шкурный интерес: я не хочу изо дня в день читать белиберду по поводу универсальных бд, волшебных паттернов, деревьев Celco, модели Тенцера и прочей бредятины. Сделайте небольшое усилие, попробуйте хотя бы почитать о распространенных точках зрения и подходах к проектированию, коль скоро Вы об этом говорите. Это правильнее и полезнее, чем то, чему "учат в университетах".
...
Рейтинг: 0 / 0
29.05.2007, 19:53
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559369
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
softwarerВ данном случае это сугубо формальный пример, иллюстрирующий, что жесткая связь существует исключительно в голове разработчика, не в инструменте.

А что именно "все всплывает", простите?

Да хотя бы план запроса изменится. Вот смотрю я на план и вижу, что вместо указанных в секции from отношений фигурируют неизвестные мне таблицы. Может я программировать не умею, но вот ни разу более менее серьёзное представление не удавалось использовать в запросе, под который оно не затачивалось изначально.

Например, ручное секционирование таблиц. Тут даже структура данных не меняется. А вот уже работает через пень.

Положим есть отношение t. Сделаем под него таблицы t1 и t2 с одинаковой структурой. Чтобы скрыть от клиентов БД детали реализации сделаем представление t:

create view t as
select * from t1
union all
select * from t2
;

Вроде всё зашибись. Но попробуем создать запрос с соединением:

select *
from t s1, other_t s2
where s1.key = s2.key;

И вот мы уже пустились в пляски с бубном, потому что выполнить такой запрос оказывается нетривиальной задачей. То индексы не цепляются, то таблица, в которой данных заведомо нет сканируется целиком. В теории, всё просто, но на практике не умеет СУБД эффективно разворачивать такие представления.

Я уж не говорю, что

insert into t values (...);

вообще не работает. Фигня вопрос, тем не менее его решение требует дополнительных затрат на кодирование приложения. А завтра DBA добавит таблицу t3...


PS. Про жёсткую связь я говорил, что "жёсткой" связи нет, но и делать эту связь гибкой далеко не всегда целесообразно, ибо гибкость усложняет систему, а сложную систему трудно сопровождать.
...
Рейтинг: 0 / 0
29.05.2007, 20:00
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559400
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenabДа хотя бы план запроса изменится.
То, что при изменении структуры данных меняется план запроса - как-то неудивительно, не находите? Это можно предсказать, не дожидаясь, пока "всплывет". Мало того, этого можно добиться куда менее серьезными изменениями, например, созданием индекса :)

mcureenabВот смотрю я на план и вижу, что вместо указанных в секции from отношений фигурируют неизвестные мне таблицы.
А кто именно "я" смотрит в план?

Даже если Вы исполняете несколько ролей или вообще один делаете все приложения начиная от концепции и заканчивая техподдержкой, стоит держать в голове "чью роль Вы исполняете в данный конкретный момент времени". Почему? Для того, чтобы применять корректную технологию, избегать "случайно получающегося" в таких случаях бардака вида "все в кучу".

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

mcureenabно и делать эту связь гибкой далеко не всегда целесообразно,
Никто не требует "делать эту связь гибкой там, где не надо". Имхо подход должен обеспечивать возможность легко и просто внедрить гибкость туда, где она потребуется - и нужно не бояться внедрять, когда потребуется. Скажем, сегодня я задаю форме X только имя таблицы - и она автоматом достраивает select/insert/update/delete. Завтра я делаю пару хранимок, указываю их имена - они цепляются вместо insert/update. Послезавтра вместо имени таблицы указываю текст select-а. Итп.

Возвращаясь к исходной теме - для меня очевидно, что неудачно выбранная структура данных будет стоить дороже, нежели кодирование одного запроса, скажем, заполняющего дерево по трем таблицам. Поэтому идея "совместить три таблицы в одну только ради того, чтобы легко заполнить treeview" представляется мне... сомнительной. Что и вызвало многократно процитированную фразу, которую мы обсуждаем.
...
Рейтинг: 0 / 0
29.05.2007, 20:22
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559403
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer
О том, что Вы передернули эти слова в самопридуманные [эпитет опущен]

я вроде цитату привел, какие еще самопридуманные? Скажите прямо то, что хотите сказать.

softwarer
iscrafmПокажите, если так осведомлены, а то не понятно о чем Вы.
Частичто об упоминаниях типа http://sql.ru/forum/actualthread.aspx?tid=255147&pg=1&hl=?, частично об... активности в более крупных обсуждениях, типа /topic/33967&pg=23#3352662

хорошо, что привели ссылки. Но неплохо было бы прочитать, что по ним написано. В первой человек спрашивает продукт для решения конкретной задачи. В качестве такого продукта предлагается Искра, тем более описанные задачи мы решаем на каждом проекте. В следующем посте предлагается BizTalk... Где реклама то? Или предложение Искры - реклама, а предложение Biz Talk - нет? Не уподобляйтесь модераторам из раздела ERP, хоть немного напрягитесь, чтобы отличить рекламу от предложений решения конкретно описанной задачи. Читайте о чем пишут. По поводу второй ссылки и последующих, если они будут. Я с удовольствием почитаю про решения, которые Вы будете предлагать для задач о которых речь идет в топиках, в качестве примеров. На пальцах можно только объяснить, что кого-то зовут "хуан". И что Вас так раздражает в подобных примерах? Это же "убогий фреймворк", не обращайте внимания


softwarer
Подумайте о том, что "тюбик из-под зубной пасты" неплохо подходит для столь разных структур, как "мягкая пища", "жидкая пища" и "газообразная пища".
Думал, много. И что. Продолжаете настаивать на том, что потребность в определенном интерфейсе не определяет потребность в определенных структурах данных и они никак не взаимосвязаны, могут разрабатываться автономно и т.д.? Под миниюбку будете пышку пристраивать? ну-ну.
...
Рейтинг: 0 / 0
29.05.2007, 20:24
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559476
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
softwarerНикто не требует "делать эту связь гибкой там, где не надо". Имхо подход должен обеспечивать возможность легко и просто внедрить гибкость туда, где она потребуется - и нужно не бояться внедрять, когда потребуется. Скажем, сегодня я задаю форме X только имя таблицы - и она автоматом достраивает select/insert/update/delete. Завтра я делаю пару хранимок, указываю их имена - они цепляются вместо insert/update. Послезавтра вместо имени таблицы указываю текст select-а. Итп.

А третьего дня, уже никто не понимает, как это работает... Если всё это нужно только ради стыковки UI с неадекватной БД, то по мне лучше миграцию БД выполнить.
Я согласен, что для решения тактических задач все эти кренделя нужны и полезны, но после тушения пожара, надо провести рефакторинг системы как на стороне приложений, так и на стороне БД.
...
Рейтинг: 0 / 0
29.05.2007, 21:29
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559557
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenabА третьего дня, уже никто не понимает, как это работает...
Если разработчики в голову едят... мы это кажется уже обсуждали?

mcureenabЕсли всё это нужно только ради стыковки UI с неадекватной БД,
Нет, похоже это безнадежно :(

Dixi.
...
Рейтинг: 0 / 0
29.05.2007, 22:45
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559621
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmя вроде цитату привел,
Привел. Я в ответ тоже привел цитату, опубликованную кем-то из-под Вашего логина.

iscrafmкакие еще самопридуманные?
Такие. Ту цитату, которую я привел, Вы придумали? Или может услышали где?

iscrafmСкажите прямо то, что хотите сказать.
Прямо я уже сказал. Придется, видимо, разжевать по буквам, иначе взрослые понимать не желают. Это отдельным письмом, бо много и совсем в сторону.

iscrafmхорошо, что привели ссылки. Но неплохо было бы прочитать, что по ним написано.
Я читал то, что по ним написано. Причем тогда, когда это было написано.

И не надо делать вид, что это два разовых случая. Такие вот примеры появлялись каждую неделю, первого типа - достаточно много потерли, второе - ссылка на цитату, где другой, совершенно не связанный со мной человек высказывает Вам аналогичную претензию. Иначе говоря, "в те времена" не только я считал Ваше поведение довольно навязчивой рекламой.

iscrafmГде реклама то? Или предложение Искры - реклама, а предложение Biz Talk - нет? Не уподобляйтесь модераторам из раздела ERP, хоть немного напрягитесь, чтобы отличить рекламу от предложений решения конкретно описанной задачи.
Модераторам раздела ERP, насколько я помню, Ваша активность тоже поднадоела?

Мне незачем "уподобляться", потому что я в данном случае - рядовой подписчик, который читал интересные ему форумы. Которого в свое время заметно задолбала реклама "Искры". Который иногда слышал про BizTalk, но не припомнит, чтобы здесь его кто-то рекламировал.

iscrafmЯ с удовольствием почитаю про решения, которые Вы будете предлагать для задач о которых речь идет в топиках, в качестве примеров. На пальцах можно только объяснить, что кого-то зовут "хуан".
Не делайте мину, незачем. Через стадию "попутной рекламы" своего продукта здесь прошли многие - скажем, тот же PVP. Разница заметна невооруженным взглядом. Впрочем, раз уж Вы даже вышеописанное передергивание "не понимаете"....

iscrafmИ что Вас так раздражает в подобных примерах?
Их количество (в те времена). После Вашего первого бана [кажется, в "Проектировании"] - да в общем ничего, насколько я понимаю, Вы к тому времени преодолели эту стадию.

iscrafmЭто же "убогий фреймворк", не обращайте внимания
Не становитесь в позу 1C-ника.

iscrafmДумал, много. И что.
Зависит от Вас.

iscrafmПродолжаете настаивать на том, что потребность в определенном интерфейсе не определяет потребность в определенных структурах данных
Безусловно. Потребность в определенном интерфейсе определяет потребность исключительно в определенном составе данных.

iscrafmи они никак не взаимосвязаны,
О терминологии я уже упоминал выше. Ok, давайте конкретный вопрос:

Допустим, в доставшемся Вам legacy приложении интерфейс заполнения позиций счета выглядит следующим образом:

- нажимается кнопка "добавить"
- в выпавшей форме в комбобоксе выбирается категория товара
- в той же форме в другом комбобоксе (детальном к первому) выбирается товар
- заполняется количество
- после нажатия OK в счет добавляется позиция, выпавшая форма закрывается
- после нескольких добавлений кнопка "Сохранить" вносит данные в БД

Клиент выдвигает требование переделать интерфейс следующим образом:

- нажимается кнопка "добавить"
- выпадает форма с двухуровневым деревом товаров-категорий
- в этой форме выбирается одна или несколько записей
- после нажатия OK выбранные товары добавляются в счет
- в гриде позиций им проставляется количество
- нажатие "Сохранить" вносит данные в БД.

Допустим, Вы согласились переделать интерфейс именно таким образом. Внимание, вопрос. Выполните ли Вы в ходе этой переделки хотя бы один CREATE TABLE/ALTER TABLE? Варианты ответа:

[ ] Безусловно да
[ ] Безусловно нет
[ ] Не знаю, зависит от структуры данных
[ ] Другое (что именно?)

iscrafmмогут разрабатываться автономно
Безусловно. Мало того, нормальные люди, разрабатывая структуру БД, о реализации GUI не думают.

iscrafmПод миниюбку будете пышку пристраивать?
Именно так. Под "миниюбку соответствующего пышке размера".

Если же мне потребуется переодеть пышку в брюки - выберу подходящие брюки. И в отличие, видимо, от Вас - не потребую от нее при этом поменять форму бюста.
...
Рейтинг: 0 / 0
29.05.2007, 23:39
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559654
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
softwarer
Допустим, в доставшемся Вам legacy приложении интерфейс заполнения позиций счета выглядит следующим образом:

- нажимается кнопка "добавить"
- в выпавшей форме в комбобоксе выбирается категория товара
- в той же форме в другом комбобоксе (детальном к первому) выбирается товар
- заполняется количество
- после нажатия OK в счет добавляется позиция, выпавшая форма закрывается
- после нескольких добавлений кнопка "Сохранить" вносит данные в БД

Клиент выдвигает требование переделать интерфейс следующим образом:

- нажимается кнопка "добавить"
- выпадает форма с двухуровневым деревом товаров-категорий
- в этой форме выбирается одна или несколько записей
- после нажатия OK выбранные товары добавляются в счет
- в гриде позиций им проставляется количество
- нажатие "Сохранить" вносит данные в БД.

Допустим, Вы согласились переделать интерфейс именно таким образом. Внимание, вопрос. Выполните ли Вы в ходе этой переделки хотя бы один CREATE TABLE/ALTER TABLE? Варианты ответа:

[ ] Безусловно да
[ ] Безусловно нет
[ ] Не знаю, зависит от структуры данных
[ ] Другое (что именно?)


Это слишком элементарные требования.
Давайте заменим -
- выпадает форма с двухуровневым деревом товаров-категорий
на -
- выпадает лес многоуреневых классификаторов с прикрепленными товарами. (Каждый товар может войти в разные классификаторы)
...
Рейтинг: 0 / 0
30.05.2007, 00:05
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34559901
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Сахават ЮсифовЭто слишком элементарные требования.
Давайте заменим -
Нет, Сахават, не давайте. В принципе вопрос не Вам, но если хотите, сначала будьте добры дать ответ в такой формулировке - а потом я попробую объяснить "взрослым людям", чем "изменение интерфейса" отличается от "изменения функционала" и почему "каша в голове" - это плохо.
...
Рейтинг: 0 / 0
30.05.2007, 08:45
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560240
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
softwarer Сахават ЮсифовЭто слишком элементарные требования.
Давайте заменим -
Нет, Сахават, не давайте. В принципе вопрос не Вам, но если хотите, сначала будьте добры дать ответ в такой формулировке - а потом я попробую объяснить "взрослым людям", чем "изменение интерфейса" отличается от "изменения функционала" и почему "каша в голове" - это плохо.

Это я не Валерию говорил, а Вам. :)
Вот форма. Туда можно безболезненно воткнуть еще кучу комбобоксов, пока они связаны со свойствами продукции. Но, как только заказчик попросит ввести комбобох "дорогие,..., средние, ..., дешевые" цены, то приплыли. Ну, а если бы была возможность клсссифицировать от балды, то ничего бы не случилось.
...
Рейтинг: 0 / 0
30.05.2007, 10:50
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560304
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
guest_20040621Погорячились.
Это была шутка.
guest_20040621Нотация?
Некий птичий язык для описания произвольных сущностей. На эту тему каждый может пофантазировать самостоятельно.
guest_20040621Откуда желание дать пользователю вообще что-то менять?
Такова исходная постановка задачи. Пользователь ведь это не один человек - это организация. Там есть простые юзеры и есть администраторы.
guest_20040621
И полУчите в результате огромную кучу дерьма, которую базой данных в принципе нельзя будет назвать.
Называй хоть горшком, только в печку не ставь. Главное - чтоб работало.
...
Рейтинг: 0 / 0
30.05.2007, 11:02
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560345
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
iscrafmЕсть общеизвестный пример реализации подобного подхода, называется 1С.
Я бы сказал - неудачная попытка реализации.
...
Рейтинг: 0 / 0
30.05.2007, 11:08
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560414
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
Сахават ЮсифовНу, а если бы была возможность клсссифицировать от балды, то ничего бы не случилось.
Т.е. если бы такая функциональность была бы изначально заложена. Отсюда вывод - в рамках одной функциональности меняй интерфейс как хочешь.
...
Рейтинг: 0 / 0
30.05.2007, 11:21
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560430
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Сахават ЮсифовВот форма. ... то приплыли.
Сахават, я еще вчера предложил Вам создать отдельный топик для обсуждения Вашей навязчивой идеи.
...
Рейтинг: 0 / 0
30.05.2007, 11:25
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560540
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarerТакие. Ту цитату, которую я привел, Вы придумали? Или может услышали где?
....
Прямо я уже сказал. Придется, видимо, разжевать по буквам, иначе взрослые понимать не желают. Это отдельным письмом, бо много и совсем в сторону.
....
Я читал то, что по ним написано. Причем тогда, когда это было написано.
...
И не надо делать вид, что это два разовых случая. Такие вот примеры появлялись каждую неделю, первого типа - достаточно много потерли, второе - ссылка на цитату, где другой, совершенно не связанный со мной человек высказывает Вам аналогичную претензию. Иначе говоря, "в те времена" не только я считал Ваше поведение довольно навязчивой рекламой.
....
Модераторам раздела ERP, насколько я помню, Ваша активность тоже поднадоела?
....
Мне незачем "уподобляться", потому что я в данном случае - рядовой подписчик, который читал интересные ему форумы. Которого в свое время заметно задолбала реклама "Искры". Который иногда слышал про BizTalk, но не припомнит, чтобы здесь его кто-то рекламировал.

softwarer, любому бреду есть предел. А по поводу рекламы - все же почитайте о чем речь в топиках идет и не нужно здесь комедию устраивать, клоунов и так хватает. Если Вы многочисленные пространные посты Garya про BizTalk не считаете рекламой и даже их не заметили..

softwarerНе делайте мину, незачем. Через стадию "попутной рекламы" своего продукта здесь прошли многие - скажем, тот же PVP. Разница заметна невооруженным взглядом. Впрочем, раз уж Вы даже вышеописанное передергивание "не понимаете"....
Какая еще мина. Я хочу узнать чем Вы заниматесь кроме изучения оракла и умничания в этом форуме. Некоторые высказывания наводят на мысль...

softwarer iscrafmИ что Вас так раздражает в подобных примерах?
Их количество (в те времена). После Вашего первого бана [кажется, в "Проектировании"] - да в общем ничего, насколько я понимаю, Вы к тому времени преодолели эту стадию.
Если Вам не на чем показать, то это объясняйте на пальцах. Я никакие продукты не применительно к теме не упоминаю. А упоминаю не только свои. Если они подходят в качестве примера на обсуждаемую тему.

softwarer iscrafmЭто же "убогий фреймворк", не обращайте внимания
Не становитесь в позу 1C-ника.
Встаньте из своей позы.


softwarerнормальные люди, разрабатывая структуру БД, о реализации GUI не думают.
Нормальные это кто? Себя тоже включили в их состав? Хотелось бы посмотреть на примеры систем которые Вы сделали разрабатывая структуру БД и не думая каким образом данные будут представлены в интерфейсе. Не стесняйтесь. Есть что-нибудь сложнее приведенного Вами примера (задачки)?

softwarer iscrafmПод миниюбку будете пышку пристраивать?
Именно так. Под "миниюбку соответствующего пышке размера".
все ясно. То о чем я говорил в самом начале - выглядят подобные эксперименты просто ужасно .

softwarer
Если же мне потребуется переодеть пышку в брюки - выберу подходящие брюки. И в отличие, видимо, от Вас - не потребую от нее при этом поменять форму бюста.
Вы даже с трудом представляете о чем речь. Что значит "выберу брюки"? Стиль, размеры, крой и т.п. брюк уже определены! Вы клиентам "гениальную" структуру своей БД предлагаете? А интерфейс подбираете? Ужас!
...
Рейтинг: 0 / 0
30.05.2007, 11:48
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560567
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
мод Сахават ЮсифовНу, а если бы была возможность клсссифицировать от балды, то ничего бы не случилось.
Т.е. если бы такая функциональность была бы изначально заложена. Отсюда вывод - в рамках одной функциональности меняй интерфейс как хочешь.

Я хотел сказать, что эластичность интерфейса, требует эластичность БД.
...
Рейтинг: 0 / 0
30.05.2007, 11:52
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560596
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarerя попробую объяснить "взрослым людям", чем "изменение интерфейса" отличается от "изменения функционала" и почему "каша в голове" - это плохо.
Вы сначала сами школу посетите, выясните что такое интерфейс, а что - функционал. А потом возможно и учить будете "взрослых людей". Устроили здесь цирк, непонятно к чему только.
...
Рейтинг: 0 / 0
30.05.2007, 11:57
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560669
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Некий птичий язык для описания произвольных сущностей. На эту тему каждый может
> пофантазировать самостоятельно.

Для каждой из подзадач придумывать свой птичий язык? Только "чтобы работало"?

> Такова исходная постановка задачи.

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

> Главное - чтоб работало.

Вы серьезно так думаете? По-моему, выгоднее "правильно работала". Одноразовыми могут быть гигиенические пакеты, салфетки, посуда, белье - да что угодно. Только не базы данных.
...
Рейтинг: 0 / 0
30.05.2007, 12:12
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560681
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmsoftwarer, любому бреду есть предел.
Тогда молчите.

iscrafmЕсли Вы многочисленные пространные посты Garya про BizTalk не считаете рекламой и даже их не заметили..
Я не припомню многочисленных постов Garya про BizTalk. Возможно Вы имеете в виду что-то недавнее в форуме ERP, я его уже достаточно давно не читаю. Если такое есть - безусловно, отнесся бы не лучше, чем к названному случаю.

iscrafmЯ никакие продукты не применительно к теме не упоминаю. А упоминаю не только свои.
Я уже сказал: не делайте мину. Разница между "упомянуть к теме" и "выискивать темы, в которых можно упомянуть" видна невооруженным взглядом, и у Вас было время именно второго варианта, к счастью этот период давно позади. Не хотите признавать - Ваше дело, проехали.

iscrafmНормальные это кто?
Вам поименный список? Боюсь, не готов к подобным трудозатратам.

iscrafmСебя тоже включили в их состав? Хотелось бы посмотреть на примеры систем которые Вы сделали разрабатывая структуру БД и не думая каким образом данные будут представлены в интерфейсе.
Хм. Контактируйте с одним из моих работодателей и смотрите. В Борласе, например, среди прочего разрабатывались хранилища данных "вообще без интерфейса" - то есть в проект входят собственно разработка хранилища и ETL, внедрение и запуск, а средства визуализации клиент выбирает и использует сам. Интересно было бы пофантазировать, как в этом случае я должен был бы думать о представлении данных в интерфейсе.

iscrafmвсе ясно. То о чем я говорил в самом начале - выглядят подобные эксперименты просто ужасно
Угу. Подменяете "я не умею" на "у всех будет плохо".

iscrafmВы даже с трудом представляете о чем речь. Что значит "выберу брюки"?


iscrafmСтиль, размеры, крой и т.п. брюк уже определены!
Глупость. Даже в этом у Вас каша в голове. Если Вы полагаете, что девушка - это интерфейс к брюкам........

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

Человек с минимальным талантом в соответствующей области каждой девушке подберет идущую ей юбку и каждой девушке подберет идущие ей брюки. Если Вы на это не способны - значит, Вам стоит добиваться результата в других областях. Если Вы полагаете, что существует единственно правильное решение - Вам в армию.
...
Рейтинг: 0 / 0
30.05.2007, 12:14
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560743
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
guest_20040621Для каждой из подзадач придумывать свой птичий язык? Только "чтобы работало"?
Сущности разные - язык один. Хотя разработать язык для решения конкр. задачи - это правильно.
guest_20040621Подскажите, пожалуйста.
Было в этом топике. Но на самом деле все просто - ввести (и задействовать) новую сущность без привлечения програмеров.
guest_20040621Вы серьезно так думаете? По-моему, выгоднее "правильно работала".
Ессно правильно. Это серьезный вопрос - накладные расходы в метасистемах очень велики, поэтому область применения ессно сужается. Но если задача вкладывается в эти ограничения - расходы оправданы.
...
Рейтинг: 0 / 0
30.05.2007, 12:26
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560759
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
softwarer
Девушка - это данные. Телосложение девушки - это структура данных. Одежда - это интерфейс. Девушки одинакового телосложения могут одеваться по-разному (одна и та же структура данных может отображаться разными интерфейсами). Девушки разного телосложения могут одеваться одинаково (один и тот же интерфейс может обслуживать разные структуры данных). Для получения хорошего результата применяются средства обеспечения гибкости (а именно выбор подходящего размера, фасона и прочих характеристик одежды).

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

Хороший пример. Только без жениха. Девушка, что бы соответствовать должна уметь худеть, полнеть и м...
...
Рейтинг: 0 / 0
30.05.2007, 12:30
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560765
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarerЯ не припомню многочисленных постов Garya про BizTalk.

Конечно, BizTalk это же не ISCRA Framework, в глаза так не бросается :)


softwarerЯ уже сказал: не делайте мину. Разница между "упомянуть к теме" и "выискивать темы, в которых можно упомянуть" видна невооруженным взглядом, и у Вас было время именно второго варианта, к счастью этот период давно позади. Не хотите признавать - Ваше дело, проехали.

ага, выискиваю темы про трехзвенки, фреймворки, удаленный доступ.. У меня робот на них настроен. Как только появляется, так сразу в нее постятся упоминания об ISCRA Framework. Детский сад.

softwarer iscrafmНормальные это кто?
Вам поименный список? Боюсь, не готов к подобным трудозатратам.
Нечего тогда ляпать.

softwarer iscrafmХотелось бы посмотреть на примеры систем которые Вы сделали разрабатывая структуру БД и не думая каким образом данные будут представлены в интерфейсе.
В Борласе, например, среди прочего разрабатывались хранилища данных "вообще без интерфейса" - то есть в проект входят собственно разработка хранилища и ETL, внедрение и запуск, а средства визуализации клиент выбирает и использует сам. Интересно было бы пофантазировать, как в этом случае я должен был бы думать о представлении данных в интерфейсе.

Если не занимались интерактивными системами серьезно, то зачем умничать? DWH, хм... как раз та тема, чтобы обсуждать влияние интерфейсов на структуру данных.

softwarer iscrafmвсе ясно. То о чем я говорил в самом начале - выглядят подобные эксперименты просто ужасно
Угу. Подменяете "я не умею" на "у всех будет плохо".
я то умею.

softwarer iscrafmСтиль, размеры, крой и т.п. брюк уже определены!
Глупость. Даже в этом у Вас каша в голове. Если Вы полагаете, что девушка - это интерфейс к брюкам........
комедия. я говорю о брюках как об интерфейсе. Действительно не понимаете?

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

Для начала позанимались бы системами в которых есть интерфейсы, мало того, к интерфейсам прежде всего предъявляются требования, а не к структуре данных как в DWH, на котором Вы сидите(сидели). И с учетом этих требований проектируется структура.

softwarerЧеловек с минимальным талантом в соответствующей области каждой девушке подберет идущую ей юбку и каждой девушке подберет идущие ей брюки. Если Вы на это не способны - значит, Вам стоит добиваться результата в других областях. Если Вы полагаете, что существует единственно правильное решение - Вам в армию.
Вам работодатель наверное дает задание спроектировать структуру для хранения данных. Понятно. см. предыдущий пост, все сказано.
...
Рейтинг: 0 / 0
30.05.2007, 12:32
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560786
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Сахават ЮсифовХороший пример. Только без жениха. Девушка, что бы соответствовать должна уметь худеть, полнеть и м...
На месте девушки я бы указал направление движения жениху, рассказывающему что она должна. Также напоминаю, что я зануда, и для меня не будет чрезмерно неприятным в очередной раз напомнить, что Вашу навязчивую идею я готов обсудить в отдельном топике.
...
Рейтинг: 0 / 0
30.05.2007, 12:35
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560799
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
[quot softwarerНа месте девушки я бы указал направление движения жениху, рассказывающему что она должна. Также напоминаю, что я зануда, и для меня не будет чрезмерно неприятным в очередной раз напомнить, что Вашу навязчивую идею я готов обсудить в отдельном топике.[/quot]

Ну, я уже давно чисто по теме. Девушку танцует тот и т.д.
...
Рейтинг: 0 / 0
30.05.2007, 12:39
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34560846
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Но на самом деле все просто - ввести (и задействовать) новую сущность
> без привлечения програмеров.

Вас реальный пример не затруднит привести?

На мой взгляд, есть две распространенные ситуации: кривая изначально структура данных или естественное развитие базы данных неестественными методами. Ни для одной из этих ситуаций непосредственное управление метамоделью - не решение.
...
Рейтинг: 0 / 0
30.05.2007, 12:54
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561049
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmКонечно, BizTalk это же не ISCRA Framework, в глаза так не бросается :)
Не знаю. Я мало знаю про Искру и еще меньше про BizTalk.

Если верить гуглю, мои посты есть в 15-ти топиках, в которых упоминалась ISCRA, и в 4-х, в которых упоминался BizTalk. "Топики, которые я читал, но не писал", а также "топики, из которых подобные советы были удалены" к сожалению, измерить не удастся, но разницу в "бросается в глаза" уже можно оценить.

iscrafmДетский сад.
Могу повторить: не хотите признавать - дело Ваше. Всего лишь штрих к портрету.

iscrafmНечего тогда ляпать.
Это не ляп. Это всего лишь корректный оборот, заменяющий более уместное "все кроме идиотов".

iscrafm Если не занимались интерактивными системами серьезно, то зачем умничать?
2dmidek - если читаете, как раз пример манипуляции из тех, которые я себе иногда позволяю, завершившейся вполне ожидаемым образом.

2iscrafm - я ожидал от Вас этой логической ошибки. Вернитесь и попробуйте подумать получше. Конечно, можете продолжить эту тему - таким образом подтвердите гипотезу о том, что Вас интересует не истина, а, назовем так, дискуссия.

iscrafm softwarerУгу. Подменяете "я не умею" на "у всех будет плохо".
я то умею.
Ага, именно поэтому результатом будет "выглядит просто ужасно".

iscrafmкомедия. я говорю о брюках как об интерфейсе.
Очень на то не похоже.

Впрочем, я уже разжевал Вам всю аналогию, если "говорите" - можете попытаться показать в ней собственное видение, а не бросаться на подставленную мной возможность отползти, не сказав ничего по сути (это я про упоминание DWH).
...
Рейтинг: 0 / 0
30.05.2007, 13:34
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561162
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
guest_20040621Вас реальный пример не затруднит привести?
Стандартный бухучет: номенклатура типов объектов аналитического учета (и ессно их параметров) заранее не известна, поэтому пользователь получает "пустую" БД, которую сам и наполняет - настраивает.
guest_20040621естественное развитие базы данных неестественными методами.
Примерно так, но цель оправдывает средства, т.е методы становятся вполне естественными в определенном контексте. На самом деле никакого развития БД в метасистемах не происходит - структура БД фиксирована раз и навсегда.
...
Рейтинг: 0 / 0
30.05.2007, 14:01
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561226
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer
Вы не понимаете того, что существует разница между:
1. Одни и теже данные можно представить в различных интерфейсах
2. Не все структуры данных подходят для определенного интерфейса
Если задача стоит в реализации конкретного интерфейса, то конечно структура данных проектируется с учетом требований этого интерфейса. Возможно Вам и ставят задачи спроектировать структуру для хранения определенных данных, возможно. Но когда ставится задача построения системы , которая имеет определенный интерфейс, то естественно проектирование структуры БД выполняется с учетом требований интерфейса. И денормализация выполняется в необходимых объемах и индексы специальные строятся и ... Что разжевывать очевидные вещи. Чтобы на выходе не получались пышки в миниюбках. Сядьте и подумайте получше.
...
Рейтинг: 0 / 0
30.05.2007, 14:15
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561257
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer2iscrafm - я ожидал от Вас этой логической ошибки. Вернитесь и попробуйте подумать получше. Конечно, можете продолжить эту тему - таким образом подтвердите гипотезу о том, что Вас интересует не истина, а, назовем так, дискуссия.
меня как раз интересует истина, Вы же начали дискуссию, я Вас за язык не тянул. Есть простое правило: если Вы чего-то не понимаете, то не нужно в штыки называть это глупостью. Лучше попытаться понять. Не хватает ресурсов для понимания - принять как есть.

softwarer iscrafm softwarerУгу. Подменяете "я не умею" на "у всех будет плохо".
я то умею.
Ага, именно поэтому результатом будет "выглядит просто ужасно".
я стараюсь не делать ужасных вещей. По крайней мере вьюхами не подгоняю неподходящую для задачи структуру данных.

softwarer iscrafmкомедия. я говорю о брюках как об интерфейсе.
Очень на то не похоже.
внимательней посмотрите.

softwarerВпрочем, я уже разжевал Вам всю аналогию, если "говорите" - можете попытаться показать в ней собственное видение, а не бросаться на подставленную мной возможность отползти, не сказав ничего по сути (это я про упоминание DWH).
Я высказал свое видение. Не моя вина что Вы не понимаете понятий "требуемый интерфейс" и проводите политику типа: для каждой толстушки можно подобрать достойный наряд. Забывая при этом, что заказчик хочет видеть кого-то в миниюбке 46 размера, а не 52.
...
Рейтинг: 0 / 0
30.05.2007, 14:25
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561313
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
iscrafmкогда ставится задача построения системы , которая имеет определенный интерфейс, то естественно проектирование структуры БД выполняется с учетом требований интерфейса.
у меня в библиотеке десяток вариантов построения структуры данных для организации складского учета. Разные по интерфейсной организации системы требовали разную структуру БД. Можно было бы поступить и так, как проповедуете Вы: на базовую структуру наделать вьюх и процедур для каждого интерфейса. Но "это не наш метод", оставлю его Вам. :)
...
Рейтинг: 0 / 0
30.05.2007, 14:38
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561406
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
iscrafm iscrafmкогда ставится задача построения системы , которая имеет определенный интерфейс, то естественно проектирование структуры БД выполняется с учетом требований интерфейса.
у меня в библиотеке десяток вариантов построения структуры данных для организации складского учета. Разные по интерфейсной организации системы требовали разную структуру БД. Можно было бы поступить и так, как проповедуете Вы: на базовую структуру наделать вьюх и процедур для каждого интерфейса. Но "это не наш метод", оставлю его Вам. :)

СпокойнЕе... Не надо дисукутировать с собой. Это опасно.
...
Рейтинг: 0 / 0
30.05.2007, 14:57
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561424
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
mcureenab
СпокойнЕе... Не надо дисукутировать с собой. Это опасно.
сорри, неправильно оформил сообщение :)
...
Рейтинг: 0 / 0
30.05.2007, 15:00
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561476
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
Ладно, хорош ругаться. Все вумные. Практика разная.
...
Рейтинг: 0 / 0
30.05.2007, 15:09
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561576
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmменя как раз интересует истина, Вы же начали дискуссию
Хм. Интересно, как можно отнестись к первому из названных утверждений, если учесть, что второе - легко проверяемая ложь?

iscrafmя Вас за язык не тянул.
Безусловно.

iscrafmЕсть простое правило: если Вы чего-то не понимаете, то не нужно в штыки называть это глупостью. Лучше попытаться понять. Не хватает ресурсов для понимания - принять как есть.
Согласен, хорошее правило. В качестве упражнения можете еще раз просмотреть сообщения, которые мы с Вами писали друг другу, и отфильтровать те места, в которых оно нарушалось. Даю наводку: синонимами слова "глупость" в данном случае будут "бред", "цирк", еще что-то....

Заодно подскажу Вам другое хорошее правило: аргументировать свои утверждения. Перечислю те аргументы, которые Вы использовали для подтверждения своей точки зрения:

iscrafmконечно же
:)
у меня
просто неприлично взрослым людям объяснять
ну-ну
вы сначала сами школу посетите

Чертовски убедительно.

iscrafmя стараюсь не делать ужасных вещей.
Тогда, может быть, Вы таки ответите на прямо заданный конкретный вопрос? Могу напомнить, мне не сложно:

Допустим, в доставшемся Вам legacy приложении интерфейс заполнения позиций счета выглядит следующим образом:

- нажимается кнопка "добавить"
- в выпавшей форме в комбобоксе выбирается категория товара
- в той же форме в другом комбобоксе (детальном к первому) выбирается товар
- заполняется количество
- после нажатия OK в счет добавляется позиция, выпавшая форма закрывается
- после нескольких добавлений кнопка "Сохранить" вносит данные в БД

Клиент выдвигает требование переделать интерфейс следующим образом:

- нажимается кнопка "добавить"
- выпадает форма с двухуровневым деревом товаров-категорий
- в этой форме выбирается одна или несколько записей
- после нажатия OK выбранные товары добавляются в счет
- в гриде позиций им проставляется количество
- нажатие "Сохранить" вносит данные в БД.

Допустим, Вы согласились переделать интерфейс именно таким образом. Внимание, вопрос. Выполните ли Вы в ходе этой переделки хотя бы один CREATE TABLE/ALTER TABLE? Варианты ответа:

[ ] Безусловно да
[ ] Безусловно нет
[ ] Не знаю, зависит от структуры данных
[ ] Другое (что именно?)

iscrafm По крайней мере вьюхами не подгоняю неподходящую для задачи структуру данных.
О, уже во вторую дырку полезли.

iscrafmвнимательней посмотрите.
Поскольку на этот раз Вы ответили, давайте ниже и посмотрим.

iscrafm Не моя вина что Вы не понимаете понятий "требуемый интерфейс"
Я в курсе этого понятия. Вы выдвинули требуемый интерфейс - миниюбка. Я его успешно реализовал. Если Вы не умеете формулировать требования.... стоит ли рассуждать о проектировании?

iscrafm и проводите политику типа: для каждой толстушки можно подобрать достойный наряд. Забывая при этом, что заказчик хочет видеть кого-то в миниюбке 46 размера, а не 52.


Первое: не моя вина, что Вы даже в собственной аналогии не способны свести концы с концами. У Вас было сказано "миниюбка" - я использовал "миниюбку". Если Вы не в курсе, что это фасон, а не размер - ну извините, как минимум предупреждайте заранее.

Второе: если заказчик хочет "пышку" и "миниюбку 46-го размера", я решу такую задачу - найду пышку 46-го размера. Почему-то подозреваю, что после этого Вы скажете, что пышка ростом 120см - вовсе даже и не пышка, и Вы имели в виду "пышку не менее чем 52-го размера". В этом случае - если Вы имеете в виду "клиент хочет, чтобы пышка была 52-го размера, а юбка 46-го" - Вы, думаю, сами знаете, что делать с такими клиентами, это пример уже не к проектированию.

В целом - такое впечатление, что беседа становится похожей на тот топик, в котором Вы несколько страниц пытались придумать "задачу, не решаемую на SQL", причем каждый раз, когда очередную Вашу задачу успешно решали, оказывалось, что Вас неправильно поняли и Вы имели в виду совсем другое.
...
Рейтинг: 0 / 0
30.05.2007, 15:30
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561767
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Насколько мне известно, пользовательские интерфейсы DWH прикладного уровня практически полностью определяются структурой и наполнением самого хранилища. Этот факт позволяет создавать и в короткие сроки развёртывать коробочные OLAP решения. Мы можем выбирать продукты разных производителей, но для каждого из них конечный результат будет определяться структурой хранилища. Грубо говоря, для просмотра фильма мы можем использовать чёрнобелый или цветной телевизор, HD панель, сходить в кинотеатр 35мм или IMAX, но жанр, смысл, сюжет, актёры фильма от этого не изменятся.

Пока UI работает только на чтение, то для любых визуальных представлений теоретически вполне сойдёт 1НФ, "звезда" или "снежинка". Как только мы захотим изменять данные, нам придётся вспомнить об аномалиях обновления и заняться нормализацией. Для больших систем практически невозможно построить единственно правильную схему БД. А если добавить сюда вопросы производительности и прочие физические ограничения мы получим ещё больше не идеальных, но достаточно хороших (сбалансированных относительно удовлетворения противоречивых и изменчивых требований) схем БД. Естественным желанием разработчика будет выбрать ту схему, для построения UI и прочих активных компонентов над которой требуются минимальные затраты на этапе разработки или в runtime.
Конечно, никто не делает кучу разных схем. Гораздо эффективнее строить БД ориентируясь на требования её пользователей. Но это уже вопрос методологии. Кто то моделирует данные, а затем поведение. Кто то наоборот, моделирует поведение, а затем определяет данные, необходимые для поддержки нужного поведения. Лично я предпочитаю последний подход.
...
Рейтинг: 0 / 0
30.05.2007, 16:08
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561827
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarerСогласен, хорошее правило. В качестве упражнения можете еще раз просмотреть сообщения, которые мы с Вами писали друг другу, и отфильтровать те места, в которых оно нарушалось.
Читайте внимательно. Спор подняли Вы в качестве несогласия с тем, что структура данных зависит от интерфейса. Ваши подходы я принимаю как есть и в курсе, что они существуют
iscrafmНо "это не наш метод", оставлю его Вам. :)
У Вас не зависит, ну как говорится .. успехов!


softwarerЗаодно подскажу Вам другое хорошее правило: аргументировать свои утверждения. Перечислю те аргументы, которые Вы использовали для подтверждения своей точки зрения:
А других Вы не заметили? Впрочем неудивительно. Наблюдалось не раз, с теми же высказываниями про "рекламу".

softwarer iscrafmя стараюсь не делать ужасных вещей.
Тогда, может быть, Вы таки ответите на прямо заданный конкретный вопрос? Могу напомнить, мне не сложно:

Допустим, в доставшемся Вам legacy приложении интерфейс заполнения позиций счета выглядит следующим образом:
Приведенный интерфейс можно реализовать на единой структуре данных.


softwarer iscrafm Не моя вина что Вы не понимаете понятий "требуемый интерфейс"
Я в курсе этого понятия. Вы выдвинули требуемый интерфейс - миниюбка. Я его успешно реализовал. Если Вы не умеете формулировать требования.... стоит ли рассуждать о проектировании?

Если Вы не понимаете требований... Откуда Вы знаете как я формирую требования? Мы с Вами не пересекались по "работе".

softwarerПервое: не моя вина, что Вы даже в собственной аналогии не способны свести концы с концами. У Вас было сказано "миниюбка" - я использовал "миниюбку". Если Вы не в курсе, что это фасон, а не размер - ну извините, как минимум предупреждайте заранее.

У нас наверное разные понятия о usability. Я знаю что любую вешь можно извратить до маразма, но не думал, что для Вас это норма:

softwarer
Второе: если заказчик хочет "пышку" и "миниюбку 46-го размера", я решу такую задачу - найду пышку 46-го размера. Почему-то подозреваю, что после этого Вы скажете, что пышка ростом 120см - вовсе даже и не пышка, и Вы имели в виду "пышку не менее чем 52-го размера". В этом случае - если Вы имеете в виду "клиент хочет, чтобы пышка была 52-го размера, а юбка 46-го" - Вы, думаю, сами знаете, что делать с такими клиентами, это пример уже не к проектированию.


softwarer
В целом - такое впечатление, что беседа становится похожей на тот топик, в котором Вы несколько страниц пытались придумать "задачу, не решаемую на SQL", причем каждый раз, когда очередную Вашу задачу успешно решали, оказывалось, что Вас неправильно поняли и Вы имели в виду совсем другое.
Почитайте тот топик и не вводите в заблуждение . Во-первых речь шла о невозможности решения всех задач при помощи select и необходимости использования курсоров . А разжевывать Вам подобные тонкости нет ни времени ни желания. Становится скучно.
...
Рейтинг: 0 / 0
30.05.2007, 16:18
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561856
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
mcureenab Кто то моделирует данные, а затем поведение. Кто то наоборот, моделирует поведение, а затем определяет данные, необходимые для поддержки нужного поведения. Лично я предпочитаю последний подход.
я тоже. Просто потому, что умное поведение системы тендеры выигрывать помогает. Т.е. встречают по одежке все-таки.
...
Рейтинг: 0 / 0
30.05.2007, 16:23
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561917
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> номенклатура типов объектов аналитического учета (и ессно их параметров) заранее не известна

Разве? Если Вы просто сформулируете, что скрывается за страшными словами "объект аналитического учета", сразу увидите, что это не так.

> которую сам и наполняет

Ну это как бы не то же самое, что управлять метамоделью, Вы не находите?

> никакого развития БД в метасистемах не происходит - структура БД фиксирована раз и навсегда

Полагаете, это достижение со знаком плюс?
...
Рейтинг: 0 / 0
30.05.2007, 16:32
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34561953
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
softwarer
Тогда, может быть, Вы таки ответите на прямо заданный конкретный вопрос? Могу напомнить, мне не сложно:

Допустим, в доставшемся Вам legacy приложении интерфейс заполнения позиций счета выглядит следующим образом:

- нажимается кнопка "добавить"
- в выпавшей форме в комбобоксе выбирается категория товара
- в той же форме в другом комбобоксе (детальном к первому) выбирается товар
- заполняется количество
- после нажатия OK в счет добавляется позиция, выпавшая форма закрывается
- после нескольких добавлений кнопка "Сохранить" вносит данные в БД

Клиент выдвигает требование переделать интерфейс следующим образом:

- нажимается кнопка "добавить"
- выпадает форма с двухуровневым деревом товаров-категорий
- в этой форме выбирается одна или несколько записей
- после нажатия OK выбранные товары добавляются в счет
- в гриде позиций им проставляется количество
- нажатие "Сохранить" вносит данные в БД.

Допустим, Вы согласились переделать интерфейс именно таким образом. Внимание, вопрос. Выполните ли Вы в ходе этой переделки хотя бы один CREATE TABLE/ALTER TABLE? Варианты ответа:

[ ] Безусловно да
[ ] Безусловно нет
[ ] Не знаю, зависит от структуры данных
[ ] Другое (что именно?)



Ответ специалиста: [X] Безусловно нет
Ответ инженера: [X] Безусловно нет, может быть.

Могу предположить, что двухуровневое дерево товаров-категорий не сложно построить на базе готового компонента (TreeList) простым SQL запросом с соединением отношений товаров и категорий (тут я фантазирую структуру БД исходя из того что старый интерфейс кореллирует со структурой БД). Как я отмечал постом выше, для просмотра данных их структура не имеет большого значения. Оператор SELECT позволяет представлять почти любые структуры данных в виде, подходящем для визуализации.

Однако, может статься, что получение такого списка будет занимать непозволительно много времени, а разработка модификации TreeList для двухуровневых деревьев будет слишком сложной. В этом случае, придётся рассмотреть возможность изменения структуры БД.
...
Рейтинг: 0 / 0
30.05.2007, 16:38
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562037
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
guest_20040621Разве? Если Вы просто сформулируете, что скрывается за страшными словами "объект аналитического учета", сразу увидите, что это не так.
А что тут страшного - любая абстрактная или реальная сущность, в разрезе которой надо вести учет. Список заранее не известен и может меняться по ходу дела - проверено на практике.
guest_20040621Ну это как бы не то же самое, что управлять метамоделью, Вы не находите?
Да
guest_20040621Полагаете, это достижение со знаком плюс?
Это не достижение, это необходимость, обусловленная существующими технологиями СУБД.
...
Рейтинг: 0 / 0
30.05.2007, 16:56
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562100
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Список заранее не известен

Хорошо, я по-другому сформулирую вопрос: какими общими свойствами обладают все объекты аналитического учета?

> может меняться по ходу дела

Может, все-таки приведете пример таких изменений? - будет нагляднее.
...
Рейтинг: 0 / 0
30.05.2007, 17:14
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562287
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
guest_20040621>Хорошо, я по-другому сформулирую вопрос: какими общими свойствами обладают все объекты аналитического учета?


Обычно, "наименование".
...
Рейтинг: 0 / 0
30.05.2007, 17:52
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562316
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmСпор подняли Вы в качестве несогласия с тем, что структура данных зависит от интерфейса.
Снова лжете. Я понимаю, Вы не привыкли читать, поэтому подскажу: если посмотрите, обнаружите, что первыми спорящими были Бред и КД , потом подключились tchingiz и mcureenab .

iscrafmА других Вы не заметили?
Относящихся именно к теме моего многократно процитированного заявления - мало того, что не обнаружил, их и не было. Оговорюсь, что в процитированном сжаты "практически одинаковые" заявления, в частности "конечно же, зависит" у Вас повторялось куда более одного раза.

iscrafmПриведенный интерфейс можно реализовать на единой структуре данных.
Приведены два интерфейса.

Да, можно. Именно такая задача ставилась.

iscrafmЕсли Вы не понимаете требований... Откуда Вы знаете как я формирую требования? Мы с Вами не пересекались по "работе".
Знаю - по тем требованиям, которые Вы сформулировали в предыдущих постах. А "кто и насколько понимает" - уже всем хорошо видно. Если Вы говорите "миниюбка" и "пышка", подразумевая "миниюбка 46-го размера" и "девушка 52-го размера".... ну собственно имеете право продолжать считать, что умеете их формулировать.

iscrafm softwarerПервое: не моя вина, что Вы даже в собственной аналогии не способны свести концы с концами. У Вас было сказано "миниюбка" - я использовал "миниюбку". Если Вы не в курсе, что это фасон, а не размер - ну извините, как минимум предупреждайте заранее.

У нас наверное разные понятия о usability.
В чем именно? Вообще не очень понял этого слова в таком контексте... Если говорить о usability требований, то "термины в требованиях должны использоваться либо в общеупотребимом смысле, либо после явного определения "что мы называем этим словом"" - согласны? Общеупотребимый смысл "миниюбки" можете посмотреть хотя бы в Вики.

лично с моей точки зрения лучше использовать определение "выше середины бедра", но это так, к слову

iscrafmЯ знаю что любую вешь можно извратить до маразма,
И активно этим пользуетесь.

iscrafmПочитайте тот топик
Читал, и даже активно в него писал.

iscrafm не вводите в заблуждение
Хотите сказать, "не выводите Валеру из заблуждения"?

iscrafmВо-первых речь шла о невозможности решения всех задач при помощи select и необходимости использования курсоров . А разжевывать Вам подобные тонкости нет ни времени ни желания. Становится скучно.
Угу. Сколько страниц Вы искали, и так и не смогли такую задачу найти? Хотя они есть, конечно.... Даже те средневзвешенные цены, которые Вы в конце концов выдавили из себя, я решил при помощи select без всяких курсоров.

А топик почитайте, почитайте. Тогда крутились-крутились, да не выкрутились.... если мне не изменяет память, аж до бана докрутились.
...
Рейтинг: 0 / 0
30.05.2007, 17:59
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562321
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Обычно, "наименование"

Не густо. ;)
Может, все-таки есть что-то, что и позволяет их называть объектами аналитического учета?
Может, их - объекты - можно объединить в какие-то большие группы?
...
Рейтинг: 0 / 0
30.05.2007, 18:01
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562445
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer iscrafmВо-первых речь шла о невозможности решения всех задач при помощи select и необходимости использования курсоров . А разжевывать Вам подобные тонкости нет ни времени ни желания. Становится скучно.
Угу. Сколько страниц Вы искали, и так и не смогли такую задачу найти? Хотя они есть, конечно.... Даже те средневзвешенные цены, которые Вы в конце концов выдавили из себя, я решил при помощи select без всяких курсоров.

ага, с использованием аналитических функций конкретно взятой СУБД . Может хватит ерничать? Вы бы еще вставки на java привели и с гордостью всем сообщали, что не используете курсоров, скромно заменяя их аналитическими функциями оракла. Кстати какие еще средневзвешенные цены? Вы решили даже не поняв какую задачу? :) Внимательней нужно читать, чтобы потом не утверждать, что кто-то неясно задачу ставит.

softwarerЕсли Вы говорите "миниюбка" и "пышка", подразумевая "миниюбка 46-го размера" и "девушка 52-го размера".... ну собственно имеете право продолжать считать, что умеете их формулировать
Сорри, не помню точных гостов и ту миниюбок, да и среднестатистического размера пышек. В общем-то для подобных алегорий это не нужно. Разве что Вам, под запись. Я все таки надеялся что "толстушка в миниюбке" будет понятной алегорией. Извиняюсь, ошибся :).

softwarerаж до бана докрутились.
задайте этот вопрос забанившему
...
Рейтинг: 0 / 0
30.05.2007, 18:38
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562453
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
p.s. извиняюсь softwarer, по Вашему клику прведено решение действительно простого расчета средневзвешенных цен. Невнимательно посмотрел, там было много задач.
...
Рейтинг: 0 / 0
30.05.2007, 18:42
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562455
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
guest_20040621> Обычно, "наименование"

Не густо. ;)
Может, все-таки есть что-то, что и позволяет их называть объектами аналитического учета?
Может, их - объекты - можно объединить в какие-то большие группы?

А мы и объединяем.

Весь вопрос как раз упирается в способы "объединения" (классификации).
1. Мягкая (исчисляемая) классификация опирающееся на неуникальность свойств.
2. Если каждый объект имеет уникальные свойства, то эти объкты можно объединить только одним путем - путем добавления нового неуникального свойства == внешний (жесткий) классификатор.

для случая один можно построи любой интерфейс при неизменной структуре данных.
для второго надо изменить структуру.
...
Рейтинг: 0 / 0
30.05.2007, 18:42
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562468
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
guest_20040621> Обычно, "наименование"

Не густо. ;)
Может, все-таки есть что-то, что и позволяет их называть объектами аналитического учета?
Может, их - объекты - можно объединить в какие-то большие группы?Отличительным свойством объекта аналитического учета является его способность появляться в учетных записях (проводках) в роли объекта аналитического учета. Что в свою очередь включает способ ссылки на объект в контексте базы в целом, способ выбора объекта и способ демонстрации текущего объекта.

По теме - разве РБД устроена не иерархически: База/Отношение/Кортеж?
вот объектные базы претендуют на свободу от этой иерархии: База/Объект.

так что в ОБД в части способа ссылки на объект вроде как все объекты немедленно пригодны для аналитического учета.
...
Рейтинг: 0 / 0
30.05.2007, 18:47
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562482
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafm ага, с использованием аналитических функций конкретно взятой СУБД
Ах, какая жалость. Вы шашечки искали, искали, а я взял и поехал.

iscrafmКстати какие еще средневзвешенные цены? Вы решили даже не поняв какую задачу? :) Внимательней нужно читать, чтобы потом не утверждать, что кто-то неясно задачу ставит.
Внимательнее и читайте. После нескольких страниц мучений из Вас таки выдавили постановку задачи в виде словесного описания алгоритма, после чего ее благополучно и решили.

iscrafmСорри, не помню точных гостов и ту миниюбок
Пошли отмазки?

iscrafmЯ все таки надеялся что "толстушка в миниюбке" будет понятной алегорией.
Аллегория - вещь своеобразная; в одном контексте "баба с весами" - Фемида, в другом - продавщица.

В данном случае Вы попытались использовать аллегорию как "окно, сквозь которое некто взглянет на мир Вашими глазами". Я использовал выдвинутую Вами модель, чтобы показать, что взгляд... назовем так, не "прям и однозначен".

iscrafmИзвиняюсь, ошибся :)
Так ответ-то на прямой конкретный вопрос будет или нет? Я и в третий раз могу повторить формулировку, если опять забыли.
...
Рейтинг: 0 / 0
30.05.2007, 18:50
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562530
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
2 All
Не надо забывать, что тут не все еще "состоявшиеся разработчики" (относительность термина опустим) и "у меня в голове опилки" (с). Не надо уклоняться от темы, хотя я понимаю причины такого уклонения. Во блин, чайник пытается выступить в роли модератора!

2 iscrafm
Я подразумевал, что раньше как раз и подстраивал под интерфейс структуру таблиц. Потом понял (с подачи softwarer), что это неправильно. Приведу пример. Данные таковы, что являются иерархическими с довольно большим числом уровней, порядка 30. Но для практической работы на определенной форме мне нужно отразить только два. Значит, по-вашему, я должен был сделать 30 связанных таблиц для каждого уровня? Сделал две таблицы – собственно объекты и уровни иерархии. Есть еще какие-н. варианты в этом случае кроме 30 таблиц или двух? Пользователь – только я.

> Интерфейс и структура данных - неразрывны.
В том плане, что работают вместе. А разрабатываются отдельно. Т.е. как выглядит интерфейс не должно зависеть от структуры данных и наоборот. Надо мне будет дерево (см. предыдущий пример) – сделаю дерево, нужны будут комбобоксы – сделаю комбобоксы. Все равно таблиц 2 будет. Ну а код, естественно, будет разный при разных способах реализации, а по-другому и не бывает. Ну что я тут за softwarer'а Вам все повторяю? В конце концов, мне это как-то и по статусу не положено.

> Идет борьба интерфейсов.
Я правильно понимаю, что кому-то нравится один интерфейс, а кому-то другой? И теперь архитектор БД должен сидеть и ждать, пока они договорятся, сколько ж ему таблиц рисовать – 30 или 2? А если они потом поменяют решение?

> Продолжаете настаивать на том, что потребность в определенном интерфейсе не определяет потребность в определенных СТРУКТУРАХ данных
softwarer: "Безусловно. Потребность в определенном интерфейсе определяет потребность исключительно в определенном СОСТАВЕ данных".
Правильно. Позволю себе уточнить? Имхо. Потребность в определенной информации определяет состав данных. Потребность в определенном способе визуализации информации определяет интерфейс. Так выражается опосредованная зависимость между составом (но не структурой!) данных и интерфейсом. И тут как бы все ясно и понятно. Какая тебе нужна информация, такой состав данных загоняешь в БД. В какой форме нужно выводить информацию, такой интерфейс и проектируешь. А мы здесь пытаемся выяснить структуру данных. И потребность в определенном интерфейсе не определяет потребности в определенной структуре данных.


2 Сахават Юсифов
Давайте только не будем поднимать и тут тему EAV. Если уж так хочется – плиз в топик "база товаров …", там это будет ближе к теме.
И вообще, давайте примем, что БД – это система. Теория систем гласит, что ни одна из них не может быть оптимизирована более чем по одному параметру. Тогда все дискуссии отпадут. Хочешь, чтоб была гибкая система – делай EAV. Есть устоявшаяся структура данных и желаешь обойтись меньшим количеством кода – делай стандартно. Все дальнейшее обсуждение в рамках топика я, пожалуй, не буду комментировать, ибо много и уже было.

2 mcureenab
> ИМХО, тебе надо получше познакомиться с инструментом, который собираешься использовать, тогда и вопросы многие отпадут.
Абсолютно согласен. Но, предположим, что я не буду работать с картами. Тем не менее, в базе должны быть возможности по работе с произвольными полигональными объектами. Ведь ссылки-то авторов на них есть. Как мне быть? Получается, что реализовать задачу можно ТОЛЬКО с помощью картографической подсистемы?

> Сегодня на канале ВЕСТИ рассказывали как американские чуваки в супермаркеты ходят. Если чувак не нашёл нужный ему товар, то он лучше не купит ничего, чем будет искать аналог...
Не все аналоги всем доступны, но если другого выхода не будет – придется переходить. И, кстати, если мне нужен кизлярский коньяк, то вряд ли я куплю французский в отсутствие кизлярского, хотя, в общем-то, аналоги, ибо дорого.

> Ну нету типа с именем BLOB, есть другие достаточно ёмкие типы. Наконец двоичные данные можно просто во внешних файлах хранить даже не привязывая их к БД.
Совсем не привязывать? Даже пути к ним не прописывать? А как же ссылаться?

> Придумай алгоритм…
Ага, все правильно. Но (см. выше), если не будет картографической подсистемы?

2 softwarer
> И совершенно не причина приписывать хрен знает какую глупость коллеге КД.
Спасибо, softwarer!
...
Рейтинг: 0 / 0
30.05.2007, 19:11
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562541
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer iscrafm ага, с использованием аналитических функций конкретно взятой СУБД
Ах, какая жалость. Вы шашечки искали, искали, а я взял и поехал.

ах какая жалость. Куда поехали то? Заменили один курсор на другой и привели пример без явного его открытия? Похоже на то, что предмет выучили, а как это работает не понимаете.

softwarerВнимательнее и читайте. После нескольких страниц мучений из Вас таки выдавили постановку задачи в виде словесного описания алгоритма, после чего ее благополучно и решили.

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


softwarer iscrafmСорри, не помню точных гостов и ту миниюбок
Пошли отмазки?
нет, я их действительно не помню. Могу поискать в принципе.

softwarer iscrafmИзвиняюсь, ошибся :)
Так ответ-то на прямой конкретный вопрос будет или нет? Я и в третий раз могу повторить формулировку, если опять забыли.
да забыл. Если не трудно.. о каком прямом вопросе идет речь?
...
Рейтинг: 0 / 0
30.05.2007, 19:15
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562578
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
КДЯ подразумевал, что раньше как раз и подстраивал под интерфейс структуру таблиц. Потом понял (с подачи softwarer), что это неправильно. Приведу пример. Данные таковы, что являются иерархическими с довольно большим числом уровней, порядка 30. Но для практической работы на определенной форме мне нужно отразить только два. Значит, по-вашему, я должен был сделать 30 связанных таблиц для каждого уровня? Сделал две таблицы – собственно объекты и уровни иерархии. Есть еще какие-н. варианты в этом случае кроме 30 таблиц или двух? Пользователь – только я.
нет, по-моему Вы не должны делать 30 связанных таблиц для каждого уровня. Но способ хранения данных Вы выбираете исходя из потребностей их дальнейшей визуализации или потребностей интерактивной работы с ними. Образно говоря, если Вам требуется представлять данные в виде деревьев, то Вы должны позаботиться о соответствующей структуре, хотя бы предусмотреть в таблице поле для связи с PARENT. Я говорю именно об этом.

КД
> Интерфейс и структура данных - неразрывны.
В том плане, что работают вместе. А разрабатываются отдельно. Т.е. как выглядит интерфейс не должно зависеть от структуры данных и наоборот. Надо мне будет дерево (см. предыдущий пример) – сделаю дерево, нужны будут комбобоксы – сделаю комбобоксы.

Вы не сделаете дерево, если это не предусмотрено структурой данных. Вам нет смысла делать "древовидную" структуру данных, если разрабатываемый интерфейс не предусматривает отображение деревьев. Можно конечно разрабатывать и отдельно, механически пихать в каждую таблицу PARENTID (к примеру).


КД
> Идет борьба интерфейсов.
Я правильно понимаю, что кому-то нравится один интерфейс, а кому-то другой? И теперь архитектор БД должен сидеть и ждать, пока они договорятся, сколько ж ему таблиц рисовать – 30 или 2? А если они потом поменяют решение?

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


КД
> Продолжаете настаивать на том, что потребность в определенном интерфейсе не определяет потребность в определенных СТРУКТУРАХ данных
softwarer: "Безусловно. Потребность в определенном интерфейсе определяет потребность исключительно в определенном СОСТАВЕ данных".

Состав данных никоим образом сюда не клеится. Задумайтесь сами, как содержимое таблицы может повлиять. Вы думаете разработчику интересно, что в его справочник занесут, "Маша" или "Петя"? Нет, не интересно. Единственное в данном контексте (состав данных) что интересно, так это типы и размеры данных. Но это уже вопрос структуры.

КД
И потребность в определенном интерфейсе не определяет потребности в определенной структуре данных.

Я Вам выше привел банальный пример с деревом, чтобы не углубляться в дебри. Подумайте сами, без подсказок со стороны и ссылок на softwarer. Так определяет потребность или нет?
...
Рейтинг: 0 / 0
30.05.2007, 19:39
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562609
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
КД
2 Сахават Юсифов
Давайте только не будем поднимать и тут тему EAV. Если уж так хочется – плиз в топик "база товаров …", там это будет ближе к теме.
И вообще, давайте примем, что БД – это система. Теория систем гласит, что ни одна из них не может быть оптимизирована более чем по одному параметру. Тогда все дискуссии отпадут. Хочешь, чтоб была гибкая система – делай EAV.

Разговор не о EAV.
Есть многокритериальная оптимизация.
...
Рейтинг: 0 / 0
30.05.2007, 20:02
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562646
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
guest_20040621> Не переживайте.

Спасибо, я так и делаю.

> "Все уже написано. До нас" (С)

Разве? По-моему, все самое интересное только начинается.

> Так что уже не важно слушаться ли, ерничать ли, ...

У меня совершенно шкурный интерес: я не хочу изо дня в день читать белиберду по поводу универсальных бд, волшебных паттернов, деревьев Celco, модели Тенцера и прочей бредятины. Сделайте небольшое усилие, попробуйте хотя бы почитать о распространенных точках зрения и подходах к проектированию, коль скоро Вы об этом говорите. Это правильнее и полезнее, чем то, чему "учат в университетах".

Значит, все-таки, переживаете, и это хорошо. Должен Вас обрадовать: я уже столько всего перечитал и о распространенных и о не очень распространенных точках зрения и подходах к проектированию, и столько всего напроектировал, что теперь могу, хотя и не очень охота, об этом говорить. Предполагаю, что у Вас метаданные (а они являются фундаментальной технологической единицей, обеспечивающей как сам доступ пользователя к данным так и правильное понимание данных) настолько, так скажем, ущербны, и настолько, так скажем, отораны от данных, что это приводит вот к такому взаимо(вот так самокритично)непониманию.
...
Рейтинг: 0 / 0
30.05.2007, 20:31
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562670
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> способность появляться в учетных записях (проводках) в роли объекта аналитического учета

Это следствие. Ну чем являются эти объекты аналитического учета? Можете Вы учитывать природные явления? Регистрировать разницу между оральной и ректальной температурой? Тогда что вы учитываете и анализируете? Как эти объекты по-другому можно назвать?

> Что в свою очередь включает способ ссылки на объект в контексте базы в целом,
> способ выбора объекта и способ демонстрации текущего объекта

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

> вот объектные базы претендуют на свободу от этой иерархии: База/Объект

Да это не важно. В принципе и для реляционной структуры можно путем добавления простой структуры данных перейти к такой адресации, - это не принципиально. Фишка такого перехода в чем?

> так что в ОБД в части способа ссылки на объект вроде как все объекты немедленно пригодны для
> аналитического учета

Речь не о способе представления, а о природе таких объектов и о том, что количество атрибутов, представляющих аналитический интерес, конечно.
...
Рейтинг: 0 / 0
30.05.2007, 20:45
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562679
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Предполагаю, что у Вас метаданные (а они являются фундаментальной технологической единицей,
> обеспечивающей как сам доступ пользователя к данным так и правильное понимание данных)

Напроектировали, говорите? ;)

Метаданные какого уровня Вы в данном случае имеете в виду? Почему Вы вдруг решили, что они ущербны? Как они могут быть оторваны от данных? К какому непониманию, по-Вашему, это привело?
...
Рейтинг: 0 / 0
30.05.2007, 20:52
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562712
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
guest_20040621> Предполагаю, что у Вас метаданные (а они являются фундаментальной технологической единицей,
> обеспечивающей как сам доступ пользователя к данным так и правильное понимание данных)

Напроектировали, говорите? ;)

Метаданные какого уровня Вы в данном случае имеете в виду? Почему Вы вдруг решили, что они ущербны? Как они могут быть оторваны от данных? К какому непониманию, по-Вашему, это привело?

Очень хорошие вопросы. Вы на правильном пути. Мои ответы:
Обоих уровней, в Вашем случае.
Один из уровней (главный) просто исчезает - ущербнее не придумаешь.
Оторваны, следовательно, "по полной программе".
К полному, к сожалению.
...
Рейтинг: 0 / 0
30.05.2007, 21:11
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562723
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Спасибо, Бред, у меня сегодня был тяжелый день, напоследок хоть кто-то повеселил.

> Вы на правильном пути

;) Спасибо, дружище.

> Обоих уровней, в Вашем случае.

"Обоих" - это каких именно? ;) На всякий случай напоминаю: речь идет о реляционных базах данных.

> Один из уровней (главный) просто исчезает

Вау! ;)) А можно чуть подробнее, какой-такой "главный" и куда он (и почему?) "исчезает"?
...
Рейтинг: 0 / 0
30.05.2007, 21:22
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562726
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
guest_20040621Спасибо, Бред, у меня сегодня был тяжелый день, напоследок хоть кто-то повеселил.

> Вы на правильном пути

;) Спасибо, дружище.

> Обоих уровней, в Вашем случае.

"Обоих" - это каких именно? ;) На всякий случай напоминаю: речь идет о реляционных базах данных.

> Один из уровней (главный) просто исчезает

Вау! ;)) А можно чуть подробнее, какой-такой "главный" и куда он (и почему?) "исчезает"?

Взаимно, guest! Тоже прилично напрягался. Ущербный реляционный как раз и остается, а какой-нибудь "типаERконцептуальный", соответсвенно, исчезает. Думаю Вы все понимаете. Но люди изворачиваются как-то на прикладном уровне. Вот сегодня как раз представители Informatica мне объяснили, что к R/3, например, PowerCenter обращается на уровне сущностей, а не к таблицам. Что уж говорить о пользовательском интерфейсе. Все Вы прекрасно понимаете.
...
Рейтинг: 0 / 0
30.05.2007, 21:29
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562733
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Ущербный реляционный как раз и остается, а какой-нибудь "типаERконцептуальный", соответсвенно, исчезает.

Йес!!! Мимо. Ноль очков. Еще, еще что-нибудь напишите. ;)))))

> Думаю Вы все понимаете.

Да я-то понимаю. Я же не сказал "бросайте учиться", я сказал "бросайте такие университеты". Разница, полагаю, очевидна?
...
Рейтинг: 0 / 0
30.05.2007, 21:40
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562748
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
guest_20040621> Ущербный реляционный как раз и остается, а какой-нибудь "типаERконцептуальный", соответсвенно, исчезает.

Йес!!! Мимо. Ноль очков. Еще, еще что-нибудь напишите. ;)))))

> Думаю Вы все понимаете.

Да я-то понимаю. Я же не сказал "бросайте учиться", я сказал "бросайте такие университеты". Разница, полагаю, очевидна?

Похоже мои оценки Ваших способностей оказались слишком оптимистичными. Ну не ноль очков, наверное, но Вы меня разочаровали. Приходится возвращаться к предположению: Ваши представления приводят к полному непониманию предмета обсуждения (извините, автор топика, что это не Ваш предмет про размещение земельных участков и АТО в таблицах РБД).
...
Рейтинг: 0 / 0
30.05.2007, 21:57
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562754
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> Похоже мои оценки

Вашими оценки, дружище, смело можете подтереться. Меня не беспоит мнение [здесь опущена куча определений, которые не нравятся модератору, - нужно отметить, совершенно справедливо не нравятся]. Вы даже не представляете, насколько бессмыленным набором букв выражаетесь. Мне искренне жаль Вашего работодателя.
...
Рейтинг: 0 / 0
30.05.2007, 22:06
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562785
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Давненько тут таких жарких споров не велось. Я думаю, это от жары
...
Рейтинг: 0 / 0
30.05.2007, 22:29
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562800
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
КД2 mcureenab
> ИМХО, тебе надо получше познакомиться с инструментом, который собираешься использовать, тогда и вопросы многие отпадут.
Абсолютно согласен. Но, предположим, что я не буду работать с картами. Тем не менее, в базе должны быть возможности по работе с произвольными полигональными объектами. Ведь ссылки-то авторов на них есть. Как мне быть? Получается, что реализовать задачу можно ТОЛЬКО с помощью картографической подсистемы?

Определись, что ты хочешь. В базе, работать ни с чем нельзя. Работать может СУБД или другая подсистема. Субд Оракл умеет хорошо работать с пространственными данными, СУБД Access - нет. Чем писать свой модуль Spatial Data будет проще и надёжнее использовать готовый софт.

КД> Ну нету типа с именем BLOB, есть другие достаточно ёмкие типы. Наконец двоичные данные можно просто во внешних файлах хранить даже не привязывая их к БД.
Совсем не привязывать? Даже пути к ним не прописывать? А как же ссылаться?

Ссылаться и привязывать, это несколько разные вещи. Если удобно, ссылайся по имени файла. Возможно, файл будет содержать целый атлас полигональных объектов. Тогда одного только имени файла будет недостаточно.

КД> Придумай алгоритм…
Ага, все правильно. Но (см. выше), если не будет картографической подсистемы?

См. выше... Честно говоря я не вижу смысла работать с географическими объектами не имея возможности визуализировать их.
Да. В БД Access можно создать структуры пригодные для хранения и обработки пространственных данных только средствами SQL и процедур на Visual Basic. Но мне кажется, что это будет изобретением бронированого велосипеда. Штука классная, но не ездит, ибо для человека тяжёлая очень. Что делать? Использовать танк (Оракл), или отделить броню (картографию) от велосипеда (access). Это важный архитектурный вопрос (как выбор мотора для самолёта), который определит дальнейшее развитие и успех системы.
...
Рейтинг: 0 / 0
30.05.2007, 22:42
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562860
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmах какая жалость. Куда поехали то? Заменили один курсор на другой и привели пример без явного его открытия? Похоже на то, что предмет выучили, а как это работает не понимаете.
Ай молодца.

Для информации: выполнение оператора select автоматически и в ста процентах случаев открывает неявный курсор этого select (в конкретно взятой СУБД, как Вы изволили выразиться). Таким образом, если принять Вашу схему рассуждений, получаем что Ваша задача - цитирую, "невозможности решения всех задач при помощи select и необходимости использования курсоров" - мягко говоря, бредово сформулирована и еще более бредова по сути.

С интересом жду Ваших дальнейших открытий на тему "кто что выучил и понимает".

iscrafmесли бы Вы читали, то наверное видели, что были и более подробные описания задач, которые были удалены.
И опять Вы говорите не-истину. Более подробных описаний задач там не было, и они не удалялись. Был - и был удален - огромный фрагмент кода, который Вы привели вместо постановки задачи - типа "реализуйте мне вот это".

iscrafmВ целом обсуждение этой старой темы вряд ли попадает под тему данного топика
Безусловно. Если помните, я вспомнил ее лишь в контексте "сейчас Вы ведете себя точно так же" - после чего Вы начали оспаривать "что же собственно происходило тогда".

iscrafmнет, я их действительно не помню. Могу поискать в принципе.
Верю и в то, и в другое. Вопрос в том, какой результат Вы собираетесь оттуда добыть.

"Отмазкой" я назвал использованный Вами прием: Ваша фраза создает впечатление, что только лень мешает Вам назвать ГОСТ/ТУ, трактующий использованный Вами термин удобным Вам образом. Поэтому позволю себе конкретный вопрос: если мы сойдемся на определении из Вики как на достаточно близком к общепринятому (Вы этого вроде бы не оспаривали), то:

1. Надеетесь ли Вы найти стандарт, этому определению кардинально противоречащий?
2. Полагаете ли Вы, что при трактовке аллегорий следует использовать определения из ГОСТов вместо общепринятых?

iscrafmда забыл. Если не трудно.. о каком прямом вопросе идет речь?
Вот об этом:

Допустим, в доставшемся Вам legacy приложении интерфейс заполнения позиций счета выглядит следующим образом:

- нажимается кнопка "добавить"
- в выпавшей форме в комбобоксе выбирается категория товара
- в той же форме в другом комбобоксе (детальном к первому) выбирается товар
- заполняется количество
- после нажатия OK в счет добавляется позиция, выпавшая форма закрывается
- после нескольких добавлений кнопка "Сохранить" вносит данные в БД

Клиент выдвигает требование переделать интерфейс следующим образом:

- нажимается кнопка "добавить"
- выпадает форма с двухуровневым деревом товаров-категорий
- в этой форме выбирается одна или несколько записей
- после нажатия OK выбранные товары добавляются в счет
- в гриде позиций им проставляется количество
- нажатие "Сохранить" вносит данные в БД.

Допустим, Вы согласились переделать интерфейс именно таким образом. Внимание, вопрос. Выполните ли Вы в ходе этой переделки хотя бы один CREATE TABLE/ALTER TABLE? Варианты ответа:

[ ] Безусловно да
[ ] Безусловно нет
[ ] Не знаю, зависит от структуры данных
[ ] Другое (что именно?)
...
Рейтинг: 0 / 0
30.05.2007, 23:42
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34562874
Фотография Анатолий Иванов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Анатолий Иванов
Участник
iscrafmОбразно говоря, если Вам требуется представлять данные в виде деревьев, то Вы должны позаботиться о соответствующей структуре, хотя бы предусмотреть в таблице поле для связи с PARENT. Я говорю именно об этом.

Стоп, стоп. Что значит "требуется представлять"? Есть ТЗ, например, что требуется сделать каталог товаров. С заказчиком оговаривается, какого типа каталог подразумевается. А вот потом уже под эти цели проектируется структура БД и отдельно прикидывается интерфейс, чтобы удобно было работать с каталогом товаров (а не со структурой данных в БД!). А уж после всего этого и решается как отобразить данные в заданной структуре на заданный интерфейс (кстати, почему интерфейс один? Их может быть несколько и довольно разных при одной и той же структуре данных). И вообще, зачем тогда всякие паттерны типа MVC/MVP? Как раз затем чтобы модель данных не зависела от интерфейса в первую очередь.

iscrafm
Вы не сделаете дерево, если это не предусмотрено структурой данных. Вам нет смысла делать "древовидную" структуру данных, если разрабатываемый интерфейс не предусматривает отображение деревьев. Можно конечно разрабатывать и отдельно, механически пихать в каждую таблицу PARENTID (к примеру).

Интересно, а как определить точный и обязательный критерий предусмотренности структуры данных для древовидного их представления? Не подскажете ли?

iscrafm
Нет, неправильно. Рынок насыщен ПО. Потребитель не особо вдается в подробности внутренней организации. В первую очередь выбирают интерфейс, который наиболее наглядно представит требуемую информацию и обеспечит наиболее удобный способ решения задач потребителя.

Внимание вопрос: причем тут структура БД? Правильно, ни при чем. "Требуемая информация" не равно "структура БД".
...
Рейтинг: 0 / 0
30.05.2007, 23:52
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563232
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
guest_20040621
Хорошо, я по-другому сформулирую вопрос: какими общими свойствами обладают все объекты аналитического учета?
В общем случае никакими
guest_20040621Может, все-таки приведете пример таких изменений? - будет нагляднее.

Пример не доказательство. Все течет, все меняется. А что, вы исключаете появление нового сво-ва сущности или появление новой сущности ? Как-то это странно...
...
Рейтинг: 0 / 0
31.05.2007, 09:23
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563241
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
guest_20040621Может, все-таки есть что-то, что и позволяет их называть объектами аналитического учета?
Все наоборот, сначала заводим объекты, а потом можем их использовать для учета (а можем и не использовать)
guest_20040621Может, их - объекты - можно объединить в какие-то большие группы?
Конечно можно, хотя бы по подсистемам учета.
...
Рейтинг: 0 / 0
31.05.2007, 09:27
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563250
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
мод guest_20040621
Хорошо, я по-другому сформулирую вопрос: какими общими свойствами обладают все объекты аналитического учета?
В общем случае никакими
guest_20040621Может, все-таки приведете пример таких изменений? - будет нагляднее.

Пример не доказательство. Все течет, все меняется. А что, вы исключаете появление нового сво-ва сущности или появление новой сущности ? Как-то это странно...
Надо, наверное, все же этот вопрос и связанные с ними один обсудить в отдельно ветке.
Только вот как ее назвать? "Жизненный цикл объекта в РБД?" :)
...
Рейтинг: 0 / 0
31.05.2007, 09:30
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563311
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
guest_20040621Речь о том, что приходится вводить метауровень и отказываться от реляционной структуры.
Да, именно так. Переход от прямого программирования приложений к разработке метапрограмм для создания приложений.
...
Рейтинг: 0 / 0
31.05.2007, 09:50
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563324
Prince-1777
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Prince-1777
Гость
mcureenabНасколько мне известно, пользовательские интерфейсы DWH прикладного уровня практически полностью определяются структурой и наполнением самого хранилища. Этот факт позволяет создавать и в короткие сроки развёртывать коробочные OLAP решения. Мы можем выбирать продукты разных производителей, но для каждого из них конечный результат будет определяться структурой хранилища. Грубо говоря, для просмотра фильма мы можем использовать чёрнобелый или цветной телевизор, HD панель, сходить в кинотеатр 35мм или IMAX, но жанр, смысл, сюжет, актёры фильма от этого не изменятся.

Пока UI работает только на чтение, то для любых визуальных представлений теоретически вполне сойдёт 1НФ, "звезда" или "снежинка". Как только мы захотим изменять данные, нам придётся вспомнить об аномалиях обновления и заняться нормализацией. Для больших систем практически невозможно построить единственно правильную схему БД. А если добавить сюда вопросы производительности и прочие физические ограничения мы получим ещё больше не идеальных, но достаточно хороших (сбалансированных относительно удовлетворения противоречивых и изменчивых требований) схем БД. Естественным желанием разработчика будет выбрать ту схему, для построения UI и прочих активных компонентов над которой требуются минимальные затраты на этапе разработки или в runtime.
Конечно, никто не делает кучу разных схем. Гораздо эффективнее строить БД ориентируясь на требования её пользователей. Но это уже вопрос методологии. Кто то моделирует данные, а затем поведение. Кто то наоборот, моделирует поведение, а затем определяет данные, необходимые для поддержки нужного поведения. Лично я предпочитаю последний подход.
++
Я предпочитаю проектировать от данных, так как повсюду бардак и про поведение надо клянчить у предметников, а данные можно и самому проанализировать :)
...
Рейтинг: 0 / 0
31.05.2007, 09:54
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563380
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
Prince-1777
Я предпочитаю проектировать от данных, так как повсюду бардак и про поведение надо клянчить у предметников, а данные можно и самому проанализировать :)

Пока копируете кем-то уже созданные модели (в виде "накладных" и "платежек") может и "анализируете".
...
Рейтинг: 0 / 0
31.05.2007, 10:09
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563494
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Анатолий Иванов
Стоп, стоп. Что значит "требуется представлять"? Есть ТЗ, например, что требуется сделать каталог товаров. С заказчиком оговаривается, какого типа каталог подразумевается. А вот потом уже под эти цели проектируется структура БД и отдельно прикидывается интерфейс, чтобы удобно было работать с каталогом товаров (а не со структурой данных в БД!). А уж после всего этого и решается как отобразить данные в заданной структуре на заданный интерфейс (кстати, почему интерфейс один? Их может быть несколько и довольно разных при одной и той же структуре данных). И вообще, зачем тогда всякие паттерны типа MVC/MVP? Как раз затем чтобы модель данных не зависела от интерфейса в первую очередь.
делайте так, кто же запрещает. Зачем MVC? да фиг его знает, Вы пользуетесь, Вы и отвечайте. Всем нужно деньги зарабатывать, в том числе на MVC, Bold и т.п. К тому же не нужно рассматривать понятие интерфейс как набор полей и кнопочек на форме. При действительно реальных изменениях интерфейса не поможет Вам MVC, полезете в базу.

Анатолий Иванов
Интересно, а как определить точный и обязательный критерий предусмотренности структуры данных для древовидного их представления? Не подскажете ли?
Я же не знаю какую структуру данных Вы делаете для древовидного представления. Мне по минимуму достаточно сслылки на Parent. Что Вам - понятия не имею.

Анатолий Иванов
Внимание вопрос: причем тут структура БД? Правильно, ни при чем. "Требуемая информация" не равно "структура БД".
Внимание, ответ! Не причем. Речь идет об интерфейсах.
...
Рейтинг: 0 / 0
31.05.2007, 10:39
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563556
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafmПри действительно реальных изменениях интерфейса не поможет Вам MVC, полезете в базу.
Итого, чем отличается изменение интерфейса от изменения функционала, Вы пока так и не осознали.

iscrafmВнимание, ответ! Не причем. Речь идет об интерфейсах.
Ну да, ну да. Я уже готов начасть составлять словарик для перевода с Вашего языка на общеупотребимый:

Слово в устах iscrafmОзначаетМиниюбкаТалия 80 см. в обхватеИнтерфейсФункционалСтруктураСостав......
...
Рейтинг: 0 / 0
31.05.2007, 10:50
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563558
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer
Для информации: выполнение оператора select автоматически и в ста процентах случаев открывает неявный курсор этого select
:) блин.. да Вы что

softwarer
И опять Вы говорите не-истину. Более подробных описаний задач там не было, и они не удалялись. Был - и был удален - огромный фрагмент кода, который Вы привели вместо постановки задачи - типа "реализуйте мне вот это".

А Вам нужно было цветочки нарисовать? Сорри, я не знал.


softwarer
Безусловно. Если помните, я вспомнил ее лишь в контексте "сейчас Вы ведете себя точно так же" - после чего Вы начали оспаривать "что же собственно происходило тогда".

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


softwarer
"Отмазкой" я назвал использованный Вами прием: Ваша фраза создает впечатление, что только лень мешает Вам назвать ГОСТ/ТУ, трактующий использованный Вами термин удобным Вам образом.

:) см. выше

softwarer
iscrafmда забыл. Если не трудно.. о каком прямом вопросе идет речь?
Вот об этом:

читайте внимательно, так же как мануалы.
...
Рейтинг: 0 / 0
31.05.2007, 10:50
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563612
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer
Слово в устах iscrafmОзначаетМиниюбкаТалия 80 см. в обхватеИнтерфейсФункционалСтруктураСостав......
рассказываю, чтобы Вы поняли и не засоряли топик подобными изысканиями:
Интерфейс <> функционал
Структура <> Состав
Миниюбка<>Талия
Почитайте выше, я об этом рассказывал.
в школу в общем.. Успехов.
Ну и продолжайте озвучивать подобные шедевры, весело.
...
Рейтинг: 0 / 0
31.05.2007, 10:58
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563765
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
Сахават ЮсифовНадо, наверное, все же этот вопрос и связанные с ними один обсудить в отдельно ветке.
Да, можно. А здесь заканчиваем.
...
Рейтинг: 0 / 0
31.05.2007, 11:23
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563933
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
iscrafm:) блин.. да Вы что
Я? Сообщаю Вам школьного уровня информацию о том, что Вы, по идее, "понимаете".

iscrafm softwarer
И опять Вы говорите не-истину. Более подробных описаний задач там не было, и они не удалялись. Был - и был удален - огромный фрагмент кода, который Вы привели вместо постановки задачи - типа "реализуйте мне вот это".

А Вам нужно было цветочки нарисовать? Сорри, я не знал.
И опять Вы лжете. На той же странице, чуть выше, вполне четко формулируется, что от Вас хотят и почему. Вот Вы отвечаете на это письмо, даже вполне убедительно. Значит, говорите, "не знали"?

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

сИнтересно, как Вам постановки задачи делают? Если запятую пропустят, Вы о ней сами догадаетесь? [/quot]
Если в переданной мне постановке задачи отсутствует принципиальная информация, я иду и выжимаю ее. Параллельно я пытаюсь найти меры, в результате которых в следующие разы постановка будет сделана грамотно. Меры могут быть разными - от объяснения что и как нужно, и вплоть до переданного административным образом "хватит придуриваться".

iscrafm softwarer
"Отмазкой" я назвал использованный Вами прием: Ваша фраза создает впечатление, что только лень мешает Вам назвать ГОСТ/ТУ, трактующий использованный Вами термин удобным Вам образом.

:) см. выше
Ответ выше.

iscrafm softwarer
iscrafmда забыл. Если не трудно.. о каком прямом вопросе идет речь?
Вот об этом:

читайте внимательно, так же как мануалы.[/quot]
Не беспокойтесь, читаю внимательно. Вами ответа дано не было (та фраза, которую Вы возможно считаете ответом, таковым не является).
...
Рейтинг: 0 / 0
31.05.2007, 11:51
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34563979
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarerНе беспокойтесь, читаю внимательно. Вами ответа дано не было (та фраза, которую Вы возможно считаете ответом, таковым не является).
Хорошо, если так не понимаете:
iscrafmПриведенный интерфейс можно реализовать на единой структуре данных.
отвечу так:
[X] Безусловно нет
:) наличие запятых не проверял, некогда.
...
Рейтинг: 0 / 0
31.05.2007, 11:57
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34564045
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> В общем случае никакими

Я задавал уточняющий вопрос в [4207993]. Нет желания на него ответить?

> Пример не доказательство.

Нет, не доказательство. В данном случае я хотел показать соответствие Вашего примера одному из двух тезисов, сфомулированных в [4204155].

> вы исключаете появление нового сво-ва сущности или появление новой сущности ?

Нет, не исключаю. Исключаю необходимость использования метаструктур для этого.
...
Рейтинг: 0 / 0
31.05.2007, 12:06
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34564077
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
guest_20040621> В общем случае никакими

Я задавал уточняющий вопрос в [4207993]. Нет желания на него ответить?

> Пример не доказательство.

Нет, не доказательство. В данном случае я хотел показать соответствие Вашего примера одному из двух тезисов, сфомулированных в [4204155].

> вы исключаете появление нового сво-ва сущности или появление новой сущности ?

Нет, не исключаю. Исключаю необходимость использования метаструктур для этого.

Может здесь продолжите?
...
Рейтинг: 0 / 0
31.05.2007, 12:11
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34564094
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
OK, спасибо. Итого, получаем следующее: "в делах" наше понимание здравого смысла в этом аспекте не расходится. Именно такая "независимость" и есть тот смысл, который я вложил во фразу, сказанную год с лишним назад и вдруг вызвавшую такую бучу.

О терминологии и "кто что имел в виду вчера когда сказал" предлагаю не беседовать.
...
Рейтинг: 0 / 0
31.05.2007, 12:16
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34564380
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
softwarer
ОК, разъехались.. и так насорили :)
...
Рейтинг: 0 / 0
31.05.2007, 13:11
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565208
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
iscrafm softwarer
ОК, разъехались.. и так насорили :)
Угу...
...
Рейтинг: 0 / 0
31.05.2007, 16:06
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565263
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
guest_20040621

> Что в свою очередь включает способ ссылки на объект в контексте базы в целом,
> способ выбора объекта и способ демонстрации текущего объекта

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



Я стараюсь говорить о предмете, guest, а не жалеть Вашего работодателя. Так вот. Вы ничего не понимаете. Не приходится вводить метауровень. Он итак есть. Приходится (Вам) переходить от него на "уровень реляционной структуры". Это лишний и бессмысленный шаг. Но Вы, как маньяк, делаете его раз за разом.
...
Рейтинг: 0 / 0
31.05.2007, 16:17
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565449
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenabУгу...
Вообще, с огромным опозданием до меня дошло, что наглядный пример гибкой связи данных и интерфейса у нас под носом. Одни и те же сообщения запросто могут отображаться в плоской модели форума и в дереве NNTP. Это вполне включает в себя и операции записи, и даже более сложные - например, выделение ветки в отдельный топик.
...
Рейтинг: 0 / 0
31.05.2007, 16:46
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565507
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
Бред, я думал, Вы понимаете русский язык. ОК, сами напросились. Вы тупы до безобразия. Сделайте одолжение, не адресуйте мне Ваши умозаключения. Я даже объяснять не буду, почему они тупые, - просто примите это как факт.

P.S. А университеты такие бросайте. Ничему хорошему Вас там не научат.
P.P.S. Модератору: извините, не удержался. Ничто не расстраивает меня больше, чем человеческая тупость.
P.P.P.S. Прочитавшим: приношу извинения за сообщение, не соответствующее теме обсуждения.
...
Рейтинг: 0 / 0
31.05.2007, 16:59
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565673
мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мод
Участник
guest_20040621Я задавал уточняющий вопрос в [4207993]. Нет желания на него ответить?
Чесно говоря, не понял в чем вопрос (простите)
guest_20040621
Нет, не исключаю. Исключаю необходимость использования метаструктур для этого.
Если бы существующие технологии СУБД позволяли бы делать это безболезненно, я бы согласился. Я видел одну СУБД, которая позволяла обходиться без метауровня, но это был эсперимент, а работать надо на промышленных системах.
...
Рейтинг: 0 / 0
31.05.2007, 17:40
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565705
andr_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andr_k
Гость
Мужики, блин, а почему так получается: умные люди, которым однозначно нравится их работа, начинают собачиться друг с другом до конца не вникнув в то, что говорит их собеседник? Порой одни и те же понятия называются разными словами. Может, глоссарий какой-нибудь сделать, что-ли? Ведь очевидно, что программер, работавший только на Oracle Forms, никогда не найдет общего языка с программером, работавшим только на Delphi, и оба они не найдут общего языка с программерами, работавшими на Java и .Net в трехзвенке. Разные архитектуры, разные ЯП, разные классы задач приводят к разным структурам для одних и тех же данных.
...
Рейтинг: 0 / 0
31.05.2007, 17:47
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565739
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
softwarer mcureenabУгу...
Вообще, с огромным опозданием до меня дошло, что наглядный пример гибкой связи данных и интерфейса у нас под носом. Одни и те же сообщения запросто могут отображаться в плоской модели форума и в дереве NNTP. Это вполне включает в себя и операции записи, и даже более сложные - например, выделение ветки в отдельный топик.

Да никто не против гибкой связи. Все осознают её полезность, и не говорят, что её нельзя сделать. Это вопрос здравого смысла. Допускает Framework гибкую связь, используем, не допускает, плачем, колемся, но едим кактусы или ищем другой Framework.

Чем гибче связь, чем больше степеней свободы и состояний она допускает, тем больше усилий нужно прилагать для её создания, тестирования и сопровождения.

Отображение данных, как правило самая простая наименее ограниченная задача. Практически любую структуру данных можно отобразить как угодно. Изменение данных налагает множество технических ограничений. Компоненты допускающие изменение данных наиболее сложная и капризная часть системы, в частности, требования к нормализации реляционных отношений исходят именно от задач изменения данных.
...
Рейтинг: 0 / 0
31.05.2007, 17:56
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565760
andr_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andr_k
Гость
mcureenab softwarer mcureenabУгу...
Вообще, с огромным опозданием до меня дошло, что наглядный пример гибкой связи данных и интерфейса у нас под носом. Одни и те же сообщения запросто могут отображаться в плоской модели форума и в дереве NNTP. Это вполне включает в себя и операции записи, и даже более сложные - например, выделение ветки в отдельный топик.

Да никто не против гибкой связи. Все осознают её полезность, и не говорят, что её нельзя сделать. Это вопрос здравого смысла. Допускает Framework гибкую связь, используем, не допускает, плачем, колемся, но едим кактусы или ищем другой Framework.

Чем гибче связь, чем больше степеней свободы и состояний она допускает, тем больше усилий нужно прилагать для её создания, тестирования и сопровождения.

Отображение данных, как правило самая простая наименее ограниченная задача. Практически любую структуру данных можно отобразить как угодно. Изменение данных налагает множество технических ограничений. Компоненты допускающие изменение данных наиболее сложная и капризная часть системы, в частности, требования к нормализации реляционных отношений исходят именно от задач изменения данных.
Плюс производительность системы требует пересмотра структур.
...
Рейтинг: 0 / 0
31.05.2007, 18:03
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565791
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
2 All
Я извиняюсь, что несколько торможу с ответами. Не успеваю за ходом дискуссии.


2 мод
> Отсюда вывод - в рамках одной функциональности меняй интерфейс как хочешь.
Да, один и тот же функционал может быть реализован различными вариантами интерфейсов. При этом состав и структура данных одни и те же.


2 iscrafm и softwarer
Не ругайтесь. Давайте вернем дискуссию в конструктивное русло.


2 iscrafm
> Образно говоря, если Вам требуется представлять данные в виде деревьев, то Вы должны позаботиться о соответствующей структуре, хотя бы предусмотреть в таблице поле для связи с PARENT. Я говорю именно об этом.
А если не образно, а конкретно, поле PARENT я лично ввожу, чтобы показать иерархическую связь между объектами. А будет ли оно использовано для дерева, в запросе или еще как-то – дело десятое. Вот и Анатолий Иванов правильно проиллюстрировал эту мысль.

> нет, по-моему Вы не должны делать 30 связанных таблиц для каждого уровня.
Правильно, не должен. Вот я и пришел к выводу, что достаточно 2 таблиц, чтобы отразить структуру данных. Далее над интерфейсом можно извращаться как угодно. Сейчас поле PARENT в таблице объектов. Интересно, а если я его добавлю в таблицу уровней иерархии и/или уберу из таблицы объектов, как это повлияет на функционал?

> Состав данных никоим образом сюда не клеится. Задумайтесь сами, как содержимое таблицы может повлиять. Вы думаете разработчику интересно, что в его справочник занесут, "Маша" или "Петя"? Нет, не интересно. Единственное в данном контексте (состав данных) что интересно, так это типы и размеры данных. Но это уже вопрос структуры.
Нет, кажется, мы с Вами по-разному понимаем термин "структура". Тип и размер данных – это, по-моему, свойства данных, обусловленные их природой. Содержимое таблицы – состав. А вот как выглядят сами таблицы, какие таблицы с какими соотносятся и т.д. – это уже структура.


2 Сахават Юсифов
> Есть многокритериальная оптимизация.
Кто ж спорит, конечно, есть. Но каждый из критериев, поучаствовавших в такой оптимизации, будет оптимален, если можно так выразиться, не на 100%, а только в контексте остальных критериев. Путано объяснил, но, думаю, Вы меня поняли.


2 mcureenab
> В базе, работать ни с чем нельзя. Работать может СУБД или другая подсистема.
Ну да, да. Я имел ввиду под словами "база", что это данные и то, что ими управляет (СУБД).

> Ссылаться и привязывать, это несколько разные вещи.
Я имел ввиду – организовать ссылочную целостность. '

> Честно говоря я не вижу смысла работать с географическими объектами не имея возможности визуализировать их.
О, нет! Я ведь уже описал ситуацию, когда это могло бы произойти. Ну давайте представим, что нет еще ГИС'ов. Но есть BLOB'ы. В таком случае мы бы ведь могли работать "с географическими объектами не имея возможности визуализировать их"? Да, это был бы страшный гемор, но в принципе возможно. Хотя я к гемору не призываю. Я попробую связку Access+MapInfo, если не получится, наверное, буду переходить на SQL Server+MapInfo.
...
Рейтинг: 0 / 0
31.05.2007, 18:09
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565841
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
mcureenabЧем гибче связь, чем больше степеней свободы и состояний она допускает, тем больше усилий нужно прилагать для её создания, тестирования и сопровождения.
Мне кажется, это утверждение обусловлено некоторой путаницей в понятиях. Попробую объяснить.

Давайте явно договоримся о терминологии: есть классы (то, что обычно подразумевается в ЯП - тип данных, если угодно компонент, обладающий определенными возможностями) и есть объекты (конкретные, созданные и настроенные экземпляры типа данных "класс").

Гибкость - это характеристика класса, не объекта. Гибкость означает примерно следующее: "а я могу создать и такую связь, и такую связь, и вот такую связь, и даже вот так вывернутую, просунутую, и трижды завязанную на конце связь".

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

Использование гибкого класса по трудоемкости мало отличается от использования для той же цели аналогичного негибкого класса. Можно не слишком отступив от истины сказать, что если для настройки объекта негибкого класса следует задать значения N свойств, то для аналогичной настройки объекта гибкого класса следует выбрать вариант поведения и настроить те же N свойств (то есть в сумме получается - настроить N+1 свойство). Разницы в трудоемкости тестирования - никакой (следует выполнить те же самые N тестов и проверить результаты). А вот в стоимости сопровождения проявляются преимущества гибкой связи: для решения задач, которые при гибком фреймворке решаются простейшей донастройкой, при негибком требуются нехилые усилия. Собственно, эти преимущества проявляются и при начальной разработке, но там они могут быть смикшированы искусным проектированием - в то время как в ходе сопровождения возникают задачи, "не очень ложащиеся" в исходную модель.

mcureenabОтображение данных, как правило самая простая наименее ограниченная задача.
И? Во всех примерах, которые я приводил, данные не только и не столько отображались. В том числе в том примере, в котором Вы ставили крестик.

mcureenabКомпоненты допускающие изменение данных наиболее сложная и капризная часть системы, в частности, требования к нормализации реляционных отношений исходят именно от задач изменения данных.
Вспомните тот же пример, в котором Вы ставили крестик. Где там капризная часть? В обоих случаях для модификации вызывается одна и та же ХП, в тексте которой не меняется ни один байт. Нормализация... какая нормализация? Об этом думает программист ХП; тот программист, который делает формы, от "нормализации" ну нисколько не зависит.
...
Рейтинг: 0 / 0
31.05.2007, 18:25
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565850
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
andr_kМужики, блин, а почему так получается: умные люди, которым однозначно нравится их работа, начинают собачиться друг с другом до конца не вникнув в то, что говорит их собеседник? Порой одни и те же понятия называются разными словами. Может, глоссарий какой-нибудь сделать, что-ли? Ведь очевидно, что программер, работавший только на Oracle Forms, никогда не найдет общего языка с программером, работавшим только на Delphi, и оба они не найдут общего языка с программерами, работавшими на Java и .Net в трехзвенке. Разные архитектуры, разные ЯП, разные классы задач приводят к разным структурам для одних и тех же данных.

Сомневаюсь, что от выбора архитектуры или инструмента структура реляционной БД претерпит принципиальные изменения. В деталях, да, возможно. Где то придётся изменить тип данных. Где то создать дополнительные таблицы для хранения промежуточных изменений и служебных даннных. Где то выполнить денормализацию.
Ощутимо отличаются реляционный и объектноориентированный подход к конструированию БД. Но объектную модель легко преобразовать в реляционную (теряя при этом семантику объектной модели). Т.е. речь идёт скорее о выразительных средствах и дополнительной семантике, чем о принципиальном изменении структуры БД.
...
Рейтинг: 0 / 0
31.05.2007, 18:27
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565851
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
andr_kПлюс производительность системы требует пересмотра структур.
Требует. И как правило оставляет неизменным интерфейс.
...
Рейтинг: 0 / 0
31.05.2007, 18:27
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565874
andr_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andr_k
Гость
А если будете использовать Oracle Spatial в 10, то он сам сгенерит структуру данных, плюс обеспечит аналитическими сетевыми функциями. Да и с MapInfo он дружит. А для MS SQL 2000, по-старой инф-ии, еще нужен модуль от MapInfo и аналитические сетевые функции нужно будет самому писать. Проще идти тогда по OpenSource.
...
Рейтинг: 0 / 0
31.05.2007, 18:36
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565879
andr_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andr_k
Гость
Для КД
andr_kА если будете использовать Oracle Spatial в 10, то он сам сгенерит структуру данных, плюс обеспечит аналитическими сетевыми функциями. Да и с MapInfo он дружит. А для MS SQL 2000, по-старой инф-ии, еще нужен модуль от MapInfo и аналитические сетевые функции нужно будет самому писать. Проще идти тогда по OpenSource.
...
Рейтинг: 0 / 0
31.05.2007, 18:37
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565885
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
guest_20040621Бред, я думал, Вы понимаете русский язык. ОК, сами напросились. Вы тупы до безобразия. Сделайте одолжение, не адресуйте мне Ваши умозаключения. Я даже объяснять не буду, почему они тупые, - просто примите это как факт.

P.S. А университеты такие бросайте. Ничему хорошему Вас там не научат.
P.P.S. Модератору: извините, не удержался. Ничто не расстраивает меня больше, чем человеческая тупость.
P.P.P.S. Прочитавшим: приношу извинения за сообщение, не соответствующее теме обсуждения.

Не ерничайте (С), модератор Вас любит. Несмотря на отсутсвие у Вас каких-либо знаний в областях, обсуждаемых на этом форуме. Вот и в этом случае сказать Вам оказалось нечего, и от досады пришлось сослаться на тупость собеседника.
PPPSSS Да и "прочитавшие" Вас не осудят, можете не извиняться.
...
Рейтинг: 0 / 0
31.05.2007, 18:42
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565933
Alexey Kudinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Kudinov
Участник
andr_kМужики, блин, а почему так получается: умные люди, которым однозначно нравится их работа, начинают собачиться друг с другом до конца не вникнув в то, что говорит их собеседник? Порой одни и те же понятия называются разными словами. Издержки письменного общения :( При личной встрече они бы сначала слегка поругались, а потом за 10 минут выяснили что говорят об одном andr_k Может, глоссарий какой-нибудь сделать, что-ли? Ведь очевидно, что программер, работавший только на Oracle Forms, никогда не найдет общего языка с программером, работавшим только на Delphi, и оба они не найдут общего языка с программерами, работавшими на Java и .Net в трехзвенке. Разные архитектуры, разные ЯП, разные классы задач приводят к разным структурам для одних и тех же данных. Да запросто договорятся, физика то везде одна и та же.
...
Рейтинг: 0 / 0
31.05.2007, 19:00
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34565949
andr_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andr_k
Гость
То Alexey Kudinov
Да хохма в том, что КД просто задал вопрос про домашний ГИС, а "мужики-то не знали".
Вы правы: за пивом общение лучше получается.
...
Рейтинг: 0 / 0
31.05.2007, 19:05
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34566279
Фотография Анатолий Иванов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Анатолий Иванов
Участник
iscrafmделайте так, кто же запрещает. Зачем MVC? да фиг его знает, Вы пользуетесь, Вы и отвечайте. Всем нужно деньги зарабатывать, в том числе на MVC, Bold и т.п. К тому же не нужно рассматривать понятие интерфейс как набор полей и кнопочек на форме. При действительно реальных изменениях интерфейса не поможет Вам MVC, полезете в базу.

Что значит при реальных изменениях интерфейса? Интерфейс сам по себе радикально не меняется просто так. Значит есть ТЗ по изменению функционала, в результате которого и будет меняться интерфейс и возможно структура БД.

iscrafm
Анатолий Иванов
Интересно, а как определить точный и обязательный критерий предусмотренности структуры данных для древовидного их представления? Не подскажете ли?
Я же не знаю какую структуру данных Вы делаете для древовидного представления. Мне по минимуму достаточно сслылки на Parent. Что Вам - понятия не имею.

Понятно, что не знаете. Я к тому и веду, что из структуры данных не обязательно вытекает ее иерархическое визуальное представление.

iscrafm
Анатолий Иванов
Внимание вопрос: причем тут структура БД? Правильно, ни при чем. "Требуемая информация" не равно "структура БД".
Внимание, ответ! Не причем. Речь идет об интерфейсах.
В том то все и дело, что для изменении интерефейса структура БД не меняется.
...
Рейтинг: 0 / 0
31.05.2007, 22:17
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34566886
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Анатолий Иванов
не хочется повторяться, почитайте выше, все разжевано до безобразия
...
Рейтинг: 0 / 0
01.06.2007, 10:53
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34566910
Prince-1777
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Prince-1777
Гость
Сахават Юсифов Prince-1777
Я предпочитаю проектировать от данных, так как повсюду бардак и про поведение надо клянчить у предметников, а данные можно и самому проанализировать :)

Пока копируете кем-то уже созданные модели (в виде "накладных" и "платежек") может и "анализируете".
Если идти от поведения - то же самое. Копируем чьи-то БП, может и анализируем. Просто по моим наблюдениям, данные более статичны, чем поведение, менее подвержены изменениям. Я говорю про здесь и сейчас. Может со временем все поменяется...
...
Рейтинг: 0 / 0
01.06.2007, 10:59
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34568298
Сахават Юсифов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сахават Юсифов
Участник
Prince-1777 Сахават Юсифов Prince-1777
Я предпочитаю проектировать от данных, так как повсюду бардак и про поведение надо клянчить у предметников, а данные можно и самому проанализировать :)

Пока копируете кем-то уже созданные модели (в виде "накладных" и "платежек") может и "анализируете".
Если идти от поведения - то же самое. Копируем чьи-то БП, может и анализируем. Просто по моим наблюдениям, данные более статичны, чем поведение, менее подвержены изменениям. Я говорю про здесь и сейчас. Может со временем все поменяется...

Предсавьте что нет никаких чужих БП, и Вы создаете среду для описания любого БП. И тогда увидете как все меняется разом, уплывают привычные статические вещи...
...
Рейтинг: 0 / 0
01.06.2007, 15:25
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #34569249
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Презентация Oracle Spatial в РДТехе
...
Рейтинг: 0 / 0
01.06.2007, 18:58
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35121101
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Знаете, я теперь стал задумываться о том, что вообще много какой информации можно хранить иерархически (т.е. изначально определить ее как таковую). Вот только нужно ли? Есть какие-н. общие алгоритмы, правила и т.д. на темы: является ли информация иерархической? если да, нужно ли это отражать в БД (т.е., нужно ли будет это пользователю?). Тут ведь и структура БД меняется, и интерфейс. У кого какие случаи бывали? Поделитесь, плиз.
...
Рейтинг: 0 / 0
08.02.2008, 18:26
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35121555
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Хранят не информацию, а данные.
Иерархическая организация это частный случай сетевой организации, но реляционные БД вообще говоря не содержат сведений об организации и подчинении объектов. Первичные и внешние ключи определяют только некие инварианты системы, но не отвечают за отношения подчинения объектов. Фактически связи записей реляционной БД кодируются в SQL запросах и могут быть любыми, в том числе и бессмысленными.
В контексте твоего первого поста можно рассматривать структуры данных, которые состоят из однотипных или разнотипных элементов. Но не факт, что однотипные элементы (так же как и разнотипные элементы) будут иметь строго иерархическую организацию.
...
Рейтинг: 0 / 0
09.02.2008, 04:46
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35121609
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Ну это все понятно. Но я не об этом спрашивал, а о том, что данные можно считать "линейными" (не состоящими в отношениях подчиненности) или "иерархическими". И, если поразмышлять, то многие данные, которые ранее казались безусловно линейными, можно посчитать и иерархическими. По какому пути пойти? Это уже даже вне контекста моего первого поста.
...
Рейтинг: 0 / 0
09.02.2008, 10:28
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35121664
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Зависит от решаемой задачи. Если наличие подчинения существенно, мы включаем его в модель данных. Проще вообще не заморачиваться этим вопросом, поскольку достаточно определить ассоциации или свяи объектов, а уж выстрояться они в дерево или нет, дело десятое. Важнее определить отношения типа "целое-часть" или "нечто есть".
...
Рейтинг: 0 / 0
09.02.2008, 11:49
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35121739
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
mcureenab пишет:
> реляционные БД вообще говоря не содержат сведений об организации и
> подчинении объектов.

Реляционные БД, как и любые другие БД, могут содержать любую информацию,
любые данные. О чем угодно.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
09.02.2008, 13:23
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35122281
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
MasterZiv
mcureenab пишет:
> реляционные БД вообще говоря не содержат сведений об организации и
> подчинении объектов.

Реляционные БД, как и любые другие БД, могут содержать любую информацию,
любые данные. О чем угодно.
Posted via ActualForum NNTP Server 1.4

Но реляционная СУБД не использует их для решения задач. т.е. если у меня в реляционной БД хранится дерево объектов, мне придётся в SQL запросе явно написать предикаты, которые позволят СУБД вернуть искомый набор данных в нужном порядке.
...
Рейтинг: 0 / 0
10.02.2008, 01:55
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35131017
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Попробуйте просто ответить на вопрос: имеет ли какая-то информация (данные) иерархичный характер? Стоит ли учитывать эту особенность в СУБД?
...
Рейтинг: 0 / 0
13.02.2008, 18:36
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35131078
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
Дык без иерархии куда: как минимум база-таблица-строка или база-объект-поле.
...
Рейтинг: 0 / 0
13.02.2008, 19:14
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35131580
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
:)
Ну, а серьезно?
...
Рейтинг: 0 / 0
14.02.2008, 06:36
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35131627
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
КД:)
Ну, а серьезно?

Не следует связи притягивать за уши.
Например, для почтовой службы чем не иерархия типа целое-часть: Страна,Область,Город,Улица,Дом,Квартира,Абонент. Однако в другой задаче нужно добавить Подъезд,Этаж. А деда Мороза почта найдёт вообще без адреса. В картографии Страна,Область,Город,Район,Улица,Дом всего лишь стили оформления полигонов, которые между собой никак не связаны, а только отображаются совместно на тех или иных слоях карты.И в самом деле, при изменении границ Города, изображения домов никуда не перемещаются, хотя почтовые адреса этих домов могут измениться.
...
Рейтинг: 0 / 0
14.02.2008, 08:30
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35131772
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
КДмногие данные, которые ранее казались безусловно линейными, можно посчитать и иерархическими. По какому пути пойти?
Объекты могут состоять (редко), а могут и не состоять(чаще) между собой в отношении иерархии.
А вот классификаторы объектов можно считать всегда иерархическими (а линенейный класификатор как частный случай иерархиии). Соответственно такому подходу проектируется и софт и UI.
...
Рейтинг: 0 / 0
14.02.2008, 09:54
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35131992
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
_модА вот классификаторы объектов можно считать всегда иерархическими
... фасетные классификаторы стройными рядами отправились курить бамбук ...
...
Рейтинг: 0 / 0
14.02.2008, 10:58
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35132060
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
softwarer ... фасетные классификаторы стройными рядами отправились курить бамбук ...
фасетный классификатор - это набор простых иерархических класификаторов ?
...
Рейтинг: 0 / 0
14.02.2008, 11:15
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35132384
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
_модфасетный классификатор - это набор простых иерархических класификаторов ?
Если коротко, то Вы излагаете теорему первого курса матана - о наличии взаимно однозначного соответствия элементов между двумя конечными множествами одинаковой мощности.
...
Рейтинг: 0 / 0
14.02.2008, 12:36
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35132505
Son_of_Morning
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Son_of_Morning
Гость
Если у тебя из предм. области заранее ничего не определено - то кроме self-join таблицы тебе ничто не поможет ИМО,
тут как и везде 2 конкурирующих параметра: общность - скорость.
...
Рейтинг: 0 / 0
14.02.2008, 13:04
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35132781
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
softwarerЕсли коротко, то Вы излагаете теорему первого курса матана
Даже не пытался :)
...
Рейтинг: 0 / 0
14.02.2008, 14:11
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35133996
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
КД:)
Ну, а серьезно?А что несерьезного? Я например не понимаю, почему в качестве отличия XML назвают иерархичность. Видимо, имеется ввиду _неограниченная_ иерархия.
А так - любой контейнер иерархичен.

Другой вопрос, как моделировать иерархию (в смысле отношение строгого порядка) прикладной области - синтаксически:
Код: plaintext
1.
2.
3.
4.
<оргструктура> 
  <подразделение name="дивизион 1">
    <подразделение name="отдел 11"/>
  </подразделение>
</оргструктура>
или явно указывать имеющее быть отношение:
Код: plaintext
1.
2.
3.
4.
<оргструктура>
   <подразделение name="дивизион 1"/>
   <подразделение name="отдел 11"/>
   <подчиняется кто="отдел 11" кому="дивизион 1"/>
</оргструктура>
Кто ж его в общем случае знает.
...
Рейтинг: 0 / 0
14.02.2008, 19:16
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35136089
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Значит, там, где объекты могут состоять в иерархичных отношениях (правда, это очень сложный вопрос - а где не могут?) - то стоит давать пользователю такую возможность (отражать их), и соответственно под это и структуру сделать и UI? А там - хотят - пусть линейно делают, хотят - иерархией? Зато у них претензий не будет, типа: почему эти данные нельзя сгруппировать вот так и вот так? - да группируйте теперь как вам угодно.
...
Рейтинг: 0 / 0
15.02.2008, 18:09
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35138233
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
КДЗначит, там, где объекты могут состоять в иерархичных отношениях (правда, это очень сложный вопрос - а где не могут?)
Чаще всего - не могут. Примеры: телефонный справочник, справочник товаров и т.д. Реальная иерархия - это состав изделия. В то же время классификатор товаров должен быть иерархическим.
...
Рейтинг: 0 / 0
18.02.2008, 10:00
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35139950
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
А-а, вот, наверное, в чем закавыка - я все время путаю "справочник" и "классификатор". Чаще для меня это как бы одно и тоже.
...
Рейтинг: 0 / 0
18.02.2008, 18:22
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35140138
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
_модВ то же время классификатор товаров должен быть иерархическим.

Ну не факт. Как существуют разные методы поиска, так могут существовать и разные классификаторы. Например, B-Tree индексы имеют очень широкую область применения, но и хэш и полный перебор тоже применяются в особых случаях. Можно товары классифицировать по разным категориям, но не сооружать из них дерева.
...
Рейтинг: 0 / 0
18.02.2008, 20:06
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35140493
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Психология человека такова, что с явлениями окружающего мира ему удобнее работать, когда они упорядочены (и чаще всего - иерархически).
...
Рейтинг: 0 / 0
19.02.2008, 06:27
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35140567
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
КДПсихология человека такова, что с явлениями окружающего мира ему удобнее работать, когда они упорядочены (и чаще всего - иерархически).
психология конкретного человека, да.

с упорядоченными инерархически данными удобно работать только тому кто упорядочивал. Если я дам Вам свою структуру папок на диске, допустим, ... будете не один день искать нужную информацию бродя по всем деревьям. Я тоже путаюсь. Мне гораздо удобней был бы простой список снабженный множеством тегов или измерениями (как принято в многомерных кубах)
...
Рейтинг: 0 / 0
19.02.2008, 08:53
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35140609
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
mcureenab Можно товары классифицировать по разным категориям, но не сооружать из них дерева.
Дело в том, что недерево имеет тенденцию превращаться в дерево (а наоборот нет).
...
Рейтинг: 0 / 0
19.02.2008, 09:26
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35140613
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
КДА-а, вот, наверное, в чем закавыка - я все время путаю "справочник" и "классификатор". Чаще для меня это как бы одно и тоже.
Деление условно, но полезно. Справочник - это список объектов. Классификатор-список этикеток для объектов.
...
Рейтинг: 0 / 0
19.02.2008, 09:28
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35141234
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
КДПопробуйте просто ответить на вопрос: имеет ли какая-то информация (данные) иерархичный характер? Стоит ли учитывать эту особенность в СУБД?
если задано по ТЗ
- класификатор A - не меняется
- класификатор B - меняется
- класификатор любой - подключается

ЗЫ. Классификатор понятие юзеровское. Один делит на "толстые и тонкие", другой на "брюнетки" "блондинки".
В идеале система должна уметь подключить "мой любимый классификатор".
...
Рейтинг: 0 / 0
19.02.2008, 12:44
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35141550
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
_мод mcureenab Можно товары классифицировать по разным категориям, но не сооружать из них дерева.
Дело в том, что недерево имеет тенденцию превращаться в дерево (а наоборот нет).

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

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


Так что по возможности следует использовать линейные структуры, которые всегда можно преобразовать в иерархические (или представить в виде иерархии), тогда как обратное не всегда возможно.
...
Рейтинг: 0 / 0
19.02.2008, 14:17
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35141638
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
mcureenab
Извините, ничего не понял. Как дерево преобразовать в список без потери информации о дереве и как из списка построить дерево, не имея такой информации.
...
Рейтинг: 0 / 0
19.02.2008, 14:43
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35142838
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
_мод mcureenab
Извините, ничего не понял. Как дерево преобразовать в список без потери информации о дереве и как из списка построить дерево, не имея такой информации.

Есть маршрут в дереве проходящий через узлы - A, B, C. Сцепляем атрибуты этих узлов в одну запись, получаем запись вида (A, B, C). Повторяя процедуру для каждого маршрута в дереве и для каждого дерева в лесу получаем список или обычную прямоугольную таблицу.

Обратное преобразования тоже не составляет труда. Например, список
(A, B1, NULL)
(A, B2, C)

преобразуется например в такое дерево:

Код: plaintext
1.
2.
3.
A
 +-B1
 +-B2
   +-C
...
Рейтинг: 0 / 0
19.02.2008, 23:03
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35143192
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Лучше скажите, с практической точки зрения, реализация 2-х классификаторов как признаков места в дереве используется где? Это велосипед или неприменимо?
idTovar klass1 klass223 1 245 1 255 2 256 2 1______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
20.02.2008, 09:26
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35143234
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
mcureenab
Теперь понял. Но это просто разные способы представления дерева, а само дерево не перестало существовать.
...
Рейтинг: 0 / 0
20.02.2008, 09:47
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35143240
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
Petro123 Это велосипед или неприменимо?
велосипед - так всегда и делается
...
Рейтинг: 0 / 0
20.02.2008, 09:48
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35143280
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
_мод Petro123 Это велосипед или неприменимо?
велосипед - так всегда и делается
а как делается бизнес-логика-запросы для одного классифа или другого, если тут 2 разных слоя одного и того-же?
Теория, шаблоны есть где?
...
Рейтинг: 0 / 0
20.02.2008, 10:04
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35145697
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Petro123Лучше скажите, с практической точки зрения, реализация 2-х классификаторов как признаков места в дереве используется где? Это велосипед или неприменимо?
idTovar klass1 klass223 1 245 1 255 2 256 2 1______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

Конечно используется. В моей БД большинство таблиц имеют более одного B*Tree индекса. А индекс чем не классификатор, хотябы на системном уровне.
...
Рейтинг: 0 / 0
20.02.2008, 19:28
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35145739
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
_мод mcureenab
Теперь понял. Но это просто разные способы представления дерева, а само дерево не перестало существовать.

Применительно к реляционным БД разговоры деревьях не имеют большого смысла, поскольку данные в них представлены в виде реляционных отношений, а древовидные структуры формируются за пределами БД на уровне форм, отчётов и прочих приложений БД. Даже иерархические запросы возвращают не дерево, а определённым образом упорядоченное отношение. Почти любую таблицу можно преобразовать в древовидную структуру, например можно скопировать её в индексно организованную таблицу, тем самым обеспечив хранение данных в виде древовидной структуры.

Что касается проектирования БД, то декомпозиция отношений обычно приводит к логическим связям типа предок-потомок, тем самым образуя иерархию записей в таблицах.

Другой вариант, структуры типа свиное ухо, когда кортеж с многократно повторяющимися группами атрибутов транспонируют так, что каждая группа атрибутов, иногда дополненная суррогатным ключём и соответствующим внешним ключём, становится отдельной строкой в таблице. Приём спорный. Мой опыт показывает, что работать с такими структурами, не смотря на их изящество, достаточно сложно. Особо проблематично работать со структурами, где каждая отдельная запись содержит только часть PK исходного отношения. Т.е. лист в этом дереве идентифицируется всем набором записей которые образуют ветку дерева.
...
Рейтинг: 0 / 0
20.02.2008, 19:55
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35146258
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
Наличие или отсутствие иерархии закладывается на уровне концептуальной модели данных, и лишь затем реализуется в СУБД, интерфейсах, отчетах и пр. Пмсм, автор топика именно это имел ввиду. Т.е., если иерархия изначально не заложена, то потом уже будет поздно, ничего не изменишь.
...
Рейтинг: 0 / 0
21.02.2008, 09:28
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35148703
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
_модНаличие или отсутствие иерархии закладывается на уровне концептуальной модели данных, и лишь затем реализуется в СУБД, интерфейсах, отчетах и пр. Пмсм, автор топика именно это имел ввиду. Т.е., если иерархия изначально не заложена, то потом уже будет поздно, ничего не изменишь.

Если её нет в исходных данных, тогда да, но опять же, если мы можем построить B*Tree индекс, то автоматически получаем некоторую иерархическую структуру, пусть даже бессмысленную с прикладной точки зрения. А если есть, то даже если мы специально не закладывали иерархические связи в модель данных, иерархию можно будет построить когда угодно.
...
Рейтинг: 0 / 0
21.02.2008, 18:27
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35149546
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
mcureenab _модНаличие или отсутствие иерархии закладывается на уровне концептуальной модели данных, и лишь затем реализуется в СУБД, интерфейсах, отчетах и пр. Пмсм, автор топика именно это имел ввиду. Т.е., если иерархия изначально не заложена, то потом уже будет поздно, ничего не изменишь.

Если её нет в исходных данных, тогда да, но опять же, если мы можем построить B*Tree индекс, то автоматически получаем некоторую иерархическую структуру, пусть даже бессмысленную с прикладной точки зрения. А если есть, то даже если мы специально не закладывали иерархические связи в модель данных, иерархию можно будет построить когда угодно.
IMHO
B*Tree нельзя построить (бессмысленен) не на пространственных (изначально иерархических) данных
...
Рейтинг: 0 / 0
22.02.2008, 09:36
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35149557
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
mcureenabдаже если мы специально не закладывали иерархические связи в модель данных, иерархию можно будет построить когда угодно.
Вот это и вызывает большие сомнения - может лучше перезаложиться сразу, чтоб потом не переделывать.
...
Рейтинг: 0 / 0
22.02.2008, 09:40
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35151303
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
_мод mcureenabдаже если мы специально не закладывали иерархические связи в модель данных, иерархию можно будет построить когда угодно.
Вот это и вызывает большие сомнения - может лучше перезаложиться сразу, чтоб потом не переделывать.

Так переделывать ничего не нужно. Берём имеющиеся данные, и представляем их (там... в форме или отчёте) в иерархическом виде.
...
Рейтинг: 0 / 0
22.02.2008, 19:54
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35156901
КД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
КД
Гость
Всех с прошедшим праздником!

2 mcureenab
> Почти любую таблицу можно преобразовать в древовидную структуру, например можно скопировать её в индексно организованную таблицу, тем самым обеспечив хранение данных в виде древовидной структуры.
Вот можно пример, как это сделать в Access?

> Если её нет в исходных данных, тогда да, но опять же, ЕСЛИ мы можем построить B*Tree индекс, то автоматически получаем некоторую иерархическую структуру, пусть даже бессмысленную с прикладной точки зрения.


2 _мод
> Пмсм, автор топика именно это имел ввиду.
Ага.

> Т.е., если иерархия изначально не заложена, то потом уже будет поздно, ничего не изменишь.
Можно, но много делать.

> Вот это и вызывает большие сомнения - может лучше перезаложиться сразу, чтоб потом не переделывать.
Ага
...
Рейтинг: 0 / 0
27.02.2008, 06:48
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35174012
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
КД2 mcureenab
> Почти любую таблицу можно преобразовать в древовидную структуру, например можно скопировать её в индексно организованную таблицу, тем самым обеспечив хранение данных в виде древовидной структуры.
Вот можно пример, как это сделать в Access?


Можно ли это сделать конкретно в Access'е не знаю. Это было очень давно.
В оракле имеем DDL:

Код: plaintext
create table organization index ...

В результате получаем таблицу, в которой записи физически храняться в виде иерархии блоков БД, которая отражает порядок записей в PK.
...
Рейтинг: 0 / 0
05.03.2008, 21:27
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35174493
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
mcureenab IMHO это не то. Мы говорим о пользовательских данных, а не о методах быстрого доступа к плоскому столбцу в Oracle
авторИндекс-таблицы

Индекс-таблица — это таблица, которая физически построена в виде двоичного дерева относительно своего первичного ключа. Oracle, начиная с версии 6, допускает возможность не производить чтение блоков данных таблицы в тех случаях, когда в запросах на выборку данных используются только столбцы индекса. Однако при операциях добавления, обновления и удаления записей обязательно должна была участвовать основная таблица. Начиная с Oracle8, существует возможность определить таблицу, которая одновременно является и собственным индексом, что устраняет ведение двух отдельных структур. Как правило, это таблицы с короткими строками, обращение, к которым всегда производится или по первичному ключу, или полным сканированием.

Не рекомендуется использовать индекс-таблицы, если строки имеют относительно большую длину, например, свыше 20% от размера блока. В этом случае лучшим выбором является использование обычных таблиц и индексов. Для создания индекс-таблиц в предложении CREATE TABLE указываются ключевые слова ORGANIZATION INDEX. Пример создания индексно-организованной таблицы представлен в листинге 232.

SQL> CREATE TABLE TabIndex

2 (At1 NUMBER PRIMARY KEY,

3 At2 VARCHAR2(40))

4 ORGANIZATION INDEX;

Table created.



______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
...
Рейтинг: 0 / 0
06.03.2008, 09:39
| Ответить | Цитировать | Написать  
Плюсы и минусы иерархического способа хранения данных
    #35174880
mcureenab
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mcureenab
Участник
Petro123 mcureenab IMHO это не то. Мы говорим о пользовательских данных, а не о методах быстрого доступа к плоскому столбцу в Oracle
авторИндекс-таблицы
...

Так и я индекс-таблицу не с потолка взял, а построил из пользовательских данных. Причём что касается СУБД Оракл, это один из немногих случаев, когда данные физически храняться в иерархическом виде, а не в куче.
Пример индекс-таблицы иллюстрирует и тот факт, что иерархические конструкции можно построить на любых данных и для этого нет нужды описывать дополнительные колонки в таблицах и т.п.

Наконец, Кнут в "Искусстве программирования" разродился главой о деревьях. Пойду почитаю.
...
Рейтинг: 0 / 0
06.03.2008, 11:29
| Ответить | Цитировать | Написать  
232 сообщений из 232, показаны все 10 страниц
  все  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Плюсы и минусы иерархического способа хранения данных
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=32&tid=1543998]:
 0ms
get settings:
 8ms
get forum list:
 13ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 21ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 305ms
get tp. blocked users:
 2ms
others: 210ms
total:  574ms
созд. / загр.: 574ms
x
x
Закрыть


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