|
|
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Есть общеизвестный пример реализации подобного подхода, называется 1С Кроме кривых поделок Вы действительно больше ничего не видели? Видел. Я кстати не озвучил характеристику указанного варианта реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:50 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
iscrafm guest_20040621> Есть общеизвестный пример реализации подобного подхода, называется 1С Кроме кривых поделок Вы действительно больше ничего не видели? Видел. Я кстати не озвучил характеристику указанного варианта реализации. Блин, ну очем спор? Если вещь самодостаточно, то ее делат под интерфейс. Если ты не знаешь всю систему, то интерфейс делается с учетом БД (или БД создает представление для этого интерфеса). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:53 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
mcureenabАх вот Вы о чём... Относительно оператора select таблицы и представления формально (в частности на этапе компиляции) неразличимы. Но как только дело доходит до выполнения всплывает всё. Да и не только относительно select. О чем я.... я о том, что утверждение наличие некоторой "жесткой связи" для "средств класса Builder", или как там они были названы, попадает в цугцванг уже на таком элементарном примере. Что бы Вы ни назвали таблицами, я могу с противным смешком сказать, что на самом деле все строго наоборот, и это вьюха, а таблица - "другой объект". В данном случае это сугубо формальный пример, иллюстрирующий, что жесткая связь существует исключительно в голове разработчика, не в инструменте. А что именно "все всплывает", простите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 18:07 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
tchingiz Бред tchingiz Бред softwarer Первое и самое главное. Запомните это, распечатайте, повесьте на стену и ежедневно проверяйте, пока не прочувствуете на подсознательном уровне: Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот Увязывать их - одна из самых больших глупостей, которые могут быть сделаны проектировщиком. Весьма не профессиональное высказывание. Удружил "начинающему". Вы намекаете что структуры данных должны зависеть от пользовательского интрефейса и это, якобы удешевит проект, продукт и весь жизненный цикл? Ровно наоборот. Я намекаю, что пользовательский интерфейс должен зависеть от концептуальной модели данных (то есть полностью ей определяться), и, соответственно, логическая модель не должна отличаться от концептуальной. Далеко не очевидно из Ваших намеков про "удружить начинающему" что Вы не имели ввиду "зависимость структуры данных от интерфейса". Начинающим вроде меня тяжело разобраться отрицание фразы (Структура данных в БД никоим образом не должна зависеть от пользовательского интерфейса программы равно как и наоборот) == структура данных в БД должна зависеть от пользовательского интерфейса программи или пользовательский интерфейс должен зависеть, от структуры данных БД. /* Заметьте, Вы, в ходе беседы, как то плавно "структуру данных БД" заменили на "концептуальную модель". Считается, что такая подмена корректна? */ Более того, я и сейчас, после уточнения струдом понимаю, какэто пользовательский интерфейс должен зависеть от структуры данных БД. Это чтоли на реляционной БД должен быть один интерфейс, а на иерархической - другой? Я то грешным делом думал, что ГУИ надо писать по возможности независимым. Ага, корректна. И не подмена вовсе, в связи с упоминанием про концептуальную и логическую модели. Вы одних в точности цитируете, а других как-то странно интерпретируете. Реляционная и иерархическая - это разве не логические? А вот в независимости ГУИ есть мощная логика, не противоречащая моим высказываниям. Написал ГУИ для метамодели и хорошо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 18:14 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Что же касается "зависимости структуры данных от интерфейса", > то она тоже имеет место на уровне метамодели, так учат в университетах Бросайте такие университеты. Ничему хорошему Вас там не научат. Слушаюсь! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 18:20 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
> Слушаюсь! Напрасно ерничаете. Ведь так и будете продолжать считать, что нужно писать гуй для метамодели. > Я кстати не озвучил характеристику указанного варианта реализации. Вот как раз imho некстати не озвучили. :) С удовольствием бы послушал и обсудил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 18:51 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
iscrafmчтобы Вас в сторону не несло, я процитирую КДТеперь я буду смотреть как мне таблицы логичнее сделать, а не как бы их под удобный интерфейс подстроить. Вы о чем? О том, что Вы передернули эти слова в самопридуманные [эпитет опущен] почему чтобы сделать простую операцию нужно так извратиться Я понимаю, что Вы не понимаете сказанного и не хотите пытаться понять. Мы с Вами сейчас ровно в том же положении, в котором оказываются КС-программисты, пытающиеся объяснить "упертым однозвенщикам" преимущества КС; ровно в том же положении, в котором оказываются многозвенщики, пытающиеся объяснить "упертым КСовцам" преимущества многозвенки итп. iscrafmПокажите, если так осведомлены, а то не понятно о чем Вы. Частичто об упоминаниях типа http://sql.ru/forum/actualthread.aspx?tid=255147&pg=1&hl=, частично об... активности в более крупных обсуждениях, типа /topic/33967&pg=23#3352662 iscrafmпросто неприлично взрослым людям объяснять, что твердую пищу (данные) тяжело засунуть в тюбик из под зубной пасты (интерфейс). Подумайте о том, что "тюбик из-под зубной пасты" неплохо подходит для столь разных структур, как "мягкая пища", "жидкая пища" и "газообразная пища". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 18:54 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Слушаюсь! Напрасно ерничаете. Ведь так и будете продолжать считать, что нужно писать гуй для метамодели. Не переживайте. "Все уже написано. До нас" (С). Так что уже не важно слушаться ли, ерничать ли, ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 19:04 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
> Не переживайте. Спасибо, я так и делаю. > "Все уже написано. До нас" (С) Разве? По-моему, все самое интересное только начинается. > Так что уже не важно слушаться ли, ерничать ли, ... У меня совершенно шкурный интерес: я не хочу изо дня в день читать белиберду по поводу универсальных бд, волшебных паттернов, деревьев Celco, модели Тенцера и прочей бредятины. Сделайте небольшое усилие, попробуйте хотя бы почитать о распространенных точках зрения и подходах к проектированию, коль скоро Вы об этом говорите. Это правильнее и полезнее, чем то, чему "учат в университетах". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 19:53 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
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. Про жёсткую связь я говорил, что "жёсткой" связи нет, но и делать эту связь гибкой далеко не всегда целесообразно, ибо гибкость усложняет систему, а сложную систему трудно сопровождать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 20:00 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
mcureenabДа хотя бы план запроса изменится. То, что при изменении структуры данных меняется план запроса - как-то неудивительно, не находите? Это можно предсказать, не дожидаясь, пока "всплывет". Мало того, этого можно добиться куда менее серьезными изменениями, например, созданием индекса :) mcureenabВот смотрю я на план и вижу, что вместо указанных в секции from отношений фигурируют неизвестные мне таблицы. А кто именно "я" смотрит в план? Даже если Вы исполняете несколько ролей или вообще один делаете все приложения начиная от концепции и заканчивая техподдержкой, стоит держать в голове "чью роль Вы исполняете в данный конкретный момент времени". Почему? Для того, чтобы применять корректную технологию, избегать "случайно получающегося" в таких случаях бардака вида "все в кучу". Дальше, в целом по поводу вьюх - не надо абсолютизировать единственный пример, приведенный для частной иллюстрации. Я согласен с той физикой, которую Вы описываете; именно поэтому гибкости стоит достигать... назовем так, не только вьюхами. Вьюхи удобны именно как формальный пример. mcureenabно и делать эту связь гибкой далеко не всегда целесообразно, Никто не требует "делать эту связь гибкой там, где не надо". Имхо подход должен обеспечивать возможность легко и просто внедрить гибкость туда, где она потребуется - и нужно не бояться внедрять, когда потребуется. Скажем, сегодня я задаю форме X только имя таблицы - и она автоматом достраивает select/insert/update/delete. Завтра я делаю пару хранимок, указываю их имена - они цепляются вместо insert/update. Послезавтра вместо имени таблицы указываю текст select-а. Итп. Возвращаясь к исходной теме - для меня очевидно, что неудачно выбранная структура данных будет стоить дороже, нежели кодирование одного запроса, скажем, заполняющего дерево по трем таблицам. Поэтому идея "совместить три таблицы в одну только ради того, чтобы легко заполнить treeview" представляется мне... сомнительной. Что и вызвало многократно процитированную фразу, которую мы обсуждаем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 20:22 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
softwarer О том, что Вы передернули эти слова в самопридуманные [эпитет опущен] я вроде цитату привел, какие еще самопридуманные? Скажите прямо то, что хотите сказать. softwarer iscrafmПокажите, если так осведомлены, а то не понятно о чем Вы. Частичто об упоминаниях типа http://sql.ru/forum/actualthread.aspx?tid=255147&pg=1&hl=?, частично об... активности в более крупных обсуждениях, типа /topic/33967&pg=23#3352662 хорошо, что привели ссылки. Но неплохо было бы прочитать, что по ним написано. В первой человек спрашивает продукт для решения конкретной задачи. В качестве такого продукта предлагается Искра, тем более описанные задачи мы решаем на каждом проекте. В следующем посте предлагается BizTalk... Где реклама то? Или предложение Искры - реклама, а предложение Biz Talk - нет? Не уподобляйтесь модераторам из раздела ERP, хоть немного напрягитесь, чтобы отличить рекламу от предложений решения конкретно описанной задачи. Читайте о чем пишут. По поводу второй ссылки и последующих, если они будут. Я с удовольствием почитаю про решения, которые Вы будете предлагать для задач о которых речь идет в топиках, в качестве примеров. На пальцах можно только объяснить, что кого-то зовут "хуан". И что Вас так раздражает в подобных примерах? Это же "убогий фреймворк", не обращайте внимания softwarer Подумайте о том, что "тюбик из-под зубной пасты" неплохо подходит для столь разных структур, как "мягкая пища", "жидкая пища" и "газообразная пища". Думал, много. И что. Продолжаете настаивать на том, что потребность в определенном интерфейсе не определяет потребность в определенных структурах данных и они никак не взаимосвязаны, могут разрабатываться автономно и т.д.? Под миниюбку будете пышку пристраивать? ну-ну. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 20:24 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
softwarerНикто не требует "делать эту связь гибкой там, где не надо". Имхо подход должен обеспечивать возможность легко и просто внедрить гибкость туда, где она потребуется - и нужно не бояться внедрять, когда потребуется. Скажем, сегодня я задаю форме X только имя таблицы - и она автоматом достраивает select/insert/update/delete. Завтра я делаю пару хранимок, указываю их имена - они цепляются вместо insert/update. Послезавтра вместо имени таблицы указываю текст select-а. Итп. А третьего дня, уже никто не понимает, как это работает... Если всё это нужно только ради стыковки UI с неадекватной БД, то по мне лучше миграцию БД выполнить. Я согласен, что для решения тактических задач все эти кренделя нужны и полезны, но после тушения пожара, надо провести рефакторинг системы как на стороне приложений, так и на стороне БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 21:29 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
mcureenabА третьего дня, уже никто не понимает, как это работает... Если разработчики в голову едят... мы это кажется уже обсуждали? mcureenabЕсли всё это нужно только ради стыковки UI с неадекватной БД, Нет, похоже это безнадежно :( Dixi. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 22:45 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
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Под миниюбку будете пышку пристраивать? Именно так. Под "миниюбку соответствующего пышке размера". Если же мне потребуется переодеть пышку в брюки - выберу подходящие брюки. И в отличие, видимо, от Вас - не потребую от нее при этом поменять форму бюста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 23:39 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
softwarer Допустим, в доставшемся Вам legacy приложении интерфейс заполнения позиций счета выглядит следующим образом: - нажимается кнопка "добавить" - в выпавшей форме в комбобоксе выбирается категория товара - в той же форме в другом комбобоксе (детальном к первому) выбирается товар - заполняется количество - после нажатия OK в счет добавляется позиция, выпавшая форма закрывается - после нескольких добавлений кнопка "Сохранить" вносит данные в БД Клиент выдвигает требование переделать интерфейс следующим образом: - нажимается кнопка "добавить" - выпадает форма с двухуровневым деревом товаров-категорий - в этой форме выбирается одна или несколько записей - после нажатия OK выбранные товары добавляются в счет - в гриде позиций им проставляется количество - нажатие "Сохранить" вносит данные в БД. Допустим, Вы согласились переделать интерфейс именно таким образом. Внимание, вопрос. Выполните ли Вы в ходе этой переделки хотя бы один CREATE TABLE/ALTER TABLE? Варианты ответа: [ ] Безусловно да [ ] Безусловно нет [ ] Не знаю, зависит от структуры данных [ ] Другое (что именно?) Это слишком элементарные требования. Давайте заменим - - выпадает форма с двухуровневым деревом товаров-категорий на - - выпадает лес многоуреневых классификаторов с прикрепленными товарами. (Каждый товар может войти в разные классификаторы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 00:05 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовЭто слишком элементарные требования. Давайте заменим - Нет, Сахават, не давайте. В принципе вопрос не Вам, но если хотите, сначала будьте добры дать ответ в такой формулировке - а потом я попробую объяснить "взрослым людям", чем "изменение интерфейса" отличается от "изменения функционала" и почему "каша в голове" - это плохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 08:45 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
softwarer Сахават ЮсифовЭто слишком элементарные требования. Давайте заменим - Нет, Сахават, не давайте. В принципе вопрос не Вам, но если хотите, сначала будьте добры дать ответ в такой формулировке - а потом я попробую объяснить "взрослым людям", чем "изменение интерфейса" отличается от "изменения функционала" и почему "каша в голове" - это плохо. Это я не Валерию говорил, а Вам. :) Вот форма. Туда можно безболезненно воткнуть еще кучу комбобоксов, пока они связаны со свойствами продукции. Но, как только заказчик попросит ввести комбобох "дорогие,..., средние, ..., дешевые" цены, то приплыли. Ну, а если бы была возможность клсссифицировать от балды, то ничего бы не случилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 10:50 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
guest_20040621Погорячились. Это была шутка. guest_20040621Нотация? Некий птичий язык для описания произвольных сущностей. На эту тему каждый может пофантазировать самостоятельно. guest_20040621Откуда желание дать пользователю вообще что-то менять? Такова исходная постановка задачи. Пользователь ведь это не один человек - это организация. Там есть простые юзеры и есть администраторы. guest_20040621 И полУчите в результате огромную кучу дерьма, которую базой данных в принципе нельзя будет назвать. Называй хоть горшком, только в печку не ставь. Главное - чтоб работало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 11:02 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
iscrafmЕсть общеизвестный пример реализации подобного подхода, называется 1С. Я бы сказал - неудачная попытка реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 11:08 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовНу, а если бы была возможность клсссифицировать от балды, то ничего бы не случилось. Т.е. если бы такая функциональность была бы изначально заложена. Отсюда вывод - в рамках одной функциональности меняй интерфейс как хочешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 11:21 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовВот форма. ... то приплыли. Сахават, я еще вчера предложил Вам создать отдельный топик для обсуждения Вашей навязчивой идеи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 11:25 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
softwarerТакие. Ту цитату, которую я привел, Вы придумали? Или может услышали где? .... Прямо я уже сказал. Придется, видимо, разжевать по буквам, иначе взрослые понимать не желают. Это отдельным письмом, бо много и совсем в сторону. .... Я читал то, что по ним написано. Причем тогда, когда это было написано. ... И не надо делать вид, что это два разовых случая. Такие вот примеры появлялись каждую неделю, первого типа - достаточно много потерли, второе - ссылка на цитату, где другой, совершенно не связанный со мной человек высказывает Вам аналогичную претензию. Иначе говоря, "в те времена" не только я считал Ваше поведение довольно навязчивой рекламой. .... Модераторам раздела ERP, насколько я помню, Ваша активность тоже поднадоела? .... Мне незачем "уподобляться", потому что я в данном случае - рядовой подписчик, который читал интересные ему форумы. Которого в свое время заметно задолбала реклама "Искры". Который иногда слышал про BizTalk, но не припомнит, чтобы здесь его кто-то рекламировал. softwarer, любому бреду есть предел. А по поводу рекламы - все же почитайте о чем речь в топиках идет и не нужно здесь комедию устраивать, клоунов и так хватает. Если Вы многочисленные пространные посты Garya про BizTalk не считаете рекламой и даже их не заметили.. softwarerНе делайте мину, незачем. Через стадию "попутной рекламы" своего продукта здесь прошли многие - скажем, тот же PVP. Разница заметна невооруженным взглядом. Впрочем, раз уж Вы даже вышеописанное передергивание "не понимаете".... Какая еще мина. Я хочу узнать чем Вы заниматесь кроме изучения оракла и умничания в этом форуме. Некоторые высказывания наводят на мысль... softwarer iscrafmИ что Вас так раздражает в подобных примерах? Их количество (в те времена). После Вашего первого бана [кажется, в "Проектировании"] - да в общем ничего, насколько я понимаю, Вы к тому времени преодолели эту стадию. Если Вам не на чем показать, то это объясняйте на пальцах. Я никакие продукты не применительно к теме не упоминаю. А упоминаю не только свои. Если они подходят в качестве примера на обсуждаемую тему. softwarer iscrafmЭто же "убогий фреймворк", не обращайте внимания Не становитесь в позу 1C-ника. Встаньте из своей позы. softwarerнормальные люди, разрабатывая структуру БД, о реализации GUI не думают. Нормальные это кто? Себя тоже включили в их состав? Хотелось бы посмотреть на примеры систем которые Вы сделали разрабатывая структуру БД и не думая каким образом данные будут представлены в интерфейсе. Не стесняйтесь. Есть что-нибудь сложнее приведенного Вами примера (задачки)? softwarer iscrafmПод миниюбку будете пышку пристраивать? Именно так. Под "миниюбку соответствующего пышке размера". все ясно. То о чем я говорил в самом начале - выглядят подобные эксперименты просто ужасно . softwarer Если же мне потребуется переодеть пышку в брюки - выберу подходящие брюки. И в отличие, видимо, от Вас - не потребую от нее при этом поменять форму бюста. Вы даже с трудом представляете о чем речь. Что значит "выберу брюки"? Стиль, размеры, крой и т.п. брюк уже определены! Вы клиентам "гениальную" структуру своей БД предлагаете? А интерфейс подбираете? Ужас! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 11:48 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
мод Сахават ЮсифовНу, а если бы была возможность клсссифицировать от балды, то ничего бы не случилось. Т.е. если бы такая функциональность была бы изначально заложена. Отсюда вывод - в рамках одной функциональности меняй интерфейс как хочешь. Я хотел сказать, что эластичность интерфейса, требует эластичность БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 11:52 |
|
||
|
Плюсы и минусы иерархического способа хранения данных
|
|||
|---|---|---|---|
|
#18+
softwarerя попробую объяснить "взрослым людям", чем "изменение интерфейса" отличается от "изменения функционала" и почему "каша в голове" - это плохо. Вы сначала сами школу посетите, выясните что такое интерфейс, а что - функционал. А потом возможно и учить будете "взрослых людей". Устроили здесь цирк, непонятно к чему только. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 11:57 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=34558984&tid=1543998]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
58ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
72ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 395ms |

| 0 / 0 |
