guest_20040621 ASUнасколько я знаю, коммерческих СУБД такого вида не было. Хотя это вполне реляционный инструментНаправление рассуждений понятно, спасибо. Достаточно давно этим не интересовался; подумал, что какие-то реализации могли появитьсяДругой пример: реляционные языки вместо SQL. Много интересных попыток, но... они так и остались на уровне "лабораторий".
guest_20040621 ASUсемантическая модель - инфологическая модель - модели полученные проекцией ИМ на разные методологии проектированияТ. е. под "объектностью" Вы подразумеваете исключительно метод[ологию] проектирования собственно базы данных?Объектная технология имеет преимущество именно на стадии проектировании. Преимущества при кодировании - это только следствие хорошего проектного решения, если нет хорошего проектного решения, то ОО-код проигрывает обычному коду (по срокам кодирования, по скорости исполнения, по объему кода, по удобству отладки и пр.).
Но я не говорю о проектировании БД, речь о проекте в целом. Проект может включать в себя создание/использование БД, но может и не включать.

AlbertG Мое видение Мне кажется, что Вы не совсем правильно формулируете задачу: AlbertGЦель - минимизация затрат по построению интерфейса пользователяВы никогда не достигните поставленной цели, по той простой причине, что не сможете сформулировать критерии ее достижения (хотя можно сказать и наоборот, что Вы, добавив всего один оператор, к коду автоматически достигаете поставленной цели, поскольку не составит труда доказать, что этот оператор минимизирует затраты). Если интересно, то посмотрите эту статью , хотя она довольно старая (1994 г.).

AlbertG ASUВы никогда не достигните поставленной цели, по той простой причине, что не сможете сформулировать критерии ее достижения (хотя можно сказать и наоборот, что Вы, добавив всего один оператор, к коду автоматически достигаете поставленной цели, поскольку не составит труда доказать, что этот оператор минимизирует затраты). Если интересно, то посмотрите эту статью, хотя она довольно старая (1994 г.).Цель - минимизировать затраты, а не изобрести универсальную волшебную палочку. Универсальных решений не бываетВсе зависит от того, что понимать под словом "универсальность"... Если один и тот же болт можно применить в тысяче изделий, то можно ли его считать "универсальным"? Если один и тот же закон физики применяется при расчете самых разных инженерных конструкций, то можно ли считать такой закон универсальным? Если один и тот же метод применим для решения многих задач, то правильно ли его считать универсальным?
AlbertGЦели я бы скорректировал так: стандартизация проектирования базы данных наряду с уменьшением затрат по проектированию пользовательского интерфейса. И это остается частным решениемОх... как это может быть опасно!.. Помните, чем вымощена дорога в ад? Если стандартизация касается выполнения рутинных операций, то я готов согласиться с Вами. Но! Посмотрите на методики а-ля CMM... они выхолащивают творчество под тем же флагом стандартизации. Мне страшновато...
Что касается пользовательского интерфейса, то мы решаем эту задачу без всякой стандартизации. Есть дизайнер, который отвечает за то, чтобы пользовательский интерфейс был единым, простым и эргономичным. Из первонального огромного многообразия пришли к небольшому количеству видов и типоразмеров. А разработчики просто используют заготовки дизайнера. Никаких стандартов на бумаге нет, но интерфейс "стандартизован". При этом, никто никого не заставляет следовать формальностям, дизайнер творит форму, программист - содержание.

Programmer_OrtodoxБраво, коллега! Для таких заявлений нужно изрядное мужество!Мужество? Нет, просто чуть-чуть здравомыслия.
Programmer_OrtodoxУже слышу крик и топот беотийцев. Частенько и меня посещала такая мысль. Знайте, что Вы не один!Спасибо.

guest_20040621Imho количества метаинформации, описанной, в частности, в статье, ссылку на которую Вы привели, - недостаточно. Недостаточность imho имеет два источника: 1. метаинформация привязана к dbms, 2. метаинформация не рассматривается как средство описания дополнительных задач (int18, история изменений etc). Хотя вполне допускаю, что в примере дополнительные задачи просто опущены.Не понимаю, о чем идет речь. Что понимается под метаинформацией? Каков критерий достаточности?

AlbertG ASUВсе зависит от того, что понимать под словом "универсальность"... Если один и тот же болт можно применить в тысяче изделий, то можно ли его считать "универсальным"? Если один и тот же закон физики применяется при расчете самых разных инженерных конструкций, то можно ли считать такой закон универсальным? Если один и тот же метод применим для решения многих задач, то правильно ли его считать универсальным?Все вокруг относительно! Все портится ..., что не может испортится, портится тоже ... :) (с) МерфиДля меня так и осталось загадкой Ваше высказывание
AlbertGЦель - минимизировать затраты, а не изобрести универсальную волшебную палочку. Универсальных решений не бываетЧто Вы этим хотели сказать?
AlbertG ASUОх... как это может быть опасно!.. Помните, чем вымощена дорога в ад? Если стандартизация касается выполнения рутинных операций, то я готов согласиться с Вами. Но! Посмотрите на методики а-ля CMM... они выхолащивают творчество под тем же флагом стандартизации. Мне страшновато...Согласен с вами. Но именно рутинные операции "объектность" и решаетХм... Вы в этом уверены? У меня совсем иное представление об «объектности». AlbertGНапример ведение логов, перенос объекта, надобность в котором отпадает в архив, удаление его наконец с учетом логических связей с другими объектами.
Передача объектов между разными базами данных, передача самих изменений описаний классов наконец. Что еще осталось ? А - универсальные механизмы получения - записи объектов из/в БД. Помните посты с примерами Анатолия Тенцера на эту тему ? Где то есть в архивах новостейЕсли Тенцер для Вас авторитет, то продолжать разговор не имеет смысла. AlbertG ASUЧто касается пользовательского интерфейса, то мы решаем эту задачу без всякой стандартизации. Есть дизайнер, который отвечает за то, чтобы пользовательский интерфейс был единым, простым и эргономичным. Из первоначального огромного многообразия пришли к небольшому количеству видов и типоразмеров. А разработчики просто используют заготовки дизайнера. Никаких стандартов на бумаге нет, но интерфейс "стандартизован". При этом, никто никого не заставляет следовать формальностям, дизайнер творит форму, программист - содержаниеНасчет дизайна форм понятно, отдельный дизайнер - просто замечательно. У нас каждый отдельный разработчик пытается следовать стандарту, выработанному в ранние годы, и это почти всегда получается. Однако внутренний стандарт не менее важен. И тут объектная точка зрения на RDBMS может принести свои дивиденды IMHOМне кажется, что мы говорим о принципиально разных вещах. Вы уверены в том, что стандарты – это хорошо. Но это объективно не так. Стандарты, как воплощение (передового) опыта и знания имеют не только положительную, но и отрицательную сторону. Любое знание относительно, и новое знание неизбежно отрицает старое знание. Чем глубже укоренилось «старое» знание, тем тяжелее перейти к новому, а стандарты помогают укоренению. Жизнь очень динамична (в программировании особенно). Если стандарты будут меняться столь часто, как этого требует жизнь, то они перестанут быть стандартами (утратят смысл). Зачем ориентироваться на какой-то стандарт, если он сменится раньше, чем закончится проект. Если будем ориентироваться на стандарт, то мы не сможем завершить проект, поскольку придется переделывать под новый стандарт, пока переделываем, выйдет еще более новый и т.д. Аналогично, можно говорить и об опыте, опыт безусловно полезен, пока не изменились условия работы. Как только они поменялись, опыт будет мешать освоить новые приемы, которые в большей степени соответствуют изменившимся условиям (более прогрессивны). Все понимают, что освоить что-то проще, чем переучиться. Чем больше груз знаний и опыта, тем консервативнее человек.
Поэтому мы не следуем стандартам, мы следуем условиям. Дизайнер, который разрабатывает внешний вид форм, отчетов и документации – это не стандарт, это Творец. Программист, который вырабатывает приемы эффективного создания кода, - это не стандарт, это Творец. Если Вы пойдете по пути создания стандартов, то Вы убьете Творчество, Вы закостенеете раньше, чем осознаете это. «Жизнь творит порядок, но порядок жизнь не творит» Антуан де-Сент Экзюпери.

guest_20040621 ASUЧто понимается под метаинформацией?Описание структуры данныхВ статье есть описание структуры.
guest_20040621 ASUКаков критерий достаточности?Хм... я русским по белому написал: "...по моему скромному мнению..." далее по тексту. Из чего следует совершенно однозначный вывод: мне такого описания структуры данных мало. Потому что я не смогу описать с ее помощью то, что хотел быНо я не знаю, чего бы Вы хотели. Структура данных, насколько я понимаю, соответствовала задаче, решаемой в статье. guest_20040621Пара копеек в Ваш диалог с member AlbertG, если позволитеДа, конечно. guest_20040621 ASUВы уверены в том, что стандарты – это хорошо. Но это объективно не такСтандарты - это не хорошо и не плохо. Это стандартыС моей точки зрения, стандарты – это и хорошо, и плохо одновременно. Мне кажется важным понимание плюсов и минусов.
guest_20040621Вам не приходит в голову ездить на автомобиле так, как хочется, а не так, как написано в правилах дорожного движения? - ровно ту же роль играют стандарты. Вот что именно понимать под стандартами, - это вопросЕздить не так, как положено приходит в голову любому, кто
а) часами простаивает в пробках;
б) имеет необычный автомобиль (например, спортивный/гоночный, которые не предназначены для того, чтобы ездить, «как положено»).
Теперь представьте, что тех, кто недоволен правилам становится все больше, а правила меняются редко (иначе они не могут быть правилами). Возможности, предоставляемые новыми технологиями, нарастают быстрее, чем формируются и принимаются новые стандарты. Посмотрите в соседних обсуждениях нарекания в адрес SAP, BAAN и пр. С чем связано недовольство? В частности с тем, что стандарты, принятые на этих фирмах, входят в противоречие с потребностями пользователей. guest_20040621 ASUДизайнер, который разрабатывает внешний вид форм, отчетов и документации – это не стандарт, это Творец. Программист, который вырабатывает приемы эффективного создания кода, - это не стандарт, это ТворецОй, ну вот только не надо про творцов. Их настолько мало, что и говорить об этом глупоМало? Каждый человек творец. По крайней мере, я не испытываю недостатка в творческих людях. guest_20040621Дизайнер, программист - это ремесленники. Точно такие же, как и кассир супермаркета. Есть хорошие, есть посредственные, есть дауны. Даунов - сильно большеЛюди являются ремесленниками ровно в той мере, в какой их возможности скованы устаревшими стандартами, нормами, правилами.
Каков критерий отнесения человека в разряд даунов Вы используете?

AlbertG ASUПоэтому мы не следуем стандартам, мы следуем условиям. Дизайнер, который разрабатывает внешний вид форм, отчетов и документации – это не стандарт, это Творец. Программист, который вырабатывает приемы эффективного создания кода, - это не стандарт, это Творец. Если Вы пойдете по пути создания стандартов, то Вы убьете Творчество, Вы закостенеете раньше, чем осознаете это.Да, творчество это замечательно. Однако даже внутри кода должна быть стандартизацияНаверное, имеет смысл уточнить понятие стандарта. Стандарт – это изложение правил и нормативов обязательных для исполнения (помните, что было написано в ГОСТах: «Не соблюдение стандарта преследуется по закону»). Есть международные стандарты (например, ISO), есть государственные стандарты (например, ГОСТы), есть отраслевые стандарты (ОСТ), и, наконец, есть стандарты предприятия (например, ТУ – технические условия). В основе феномена стандартизации лежит желание упорядочить процессы производства, тестирования, управления и т.п., дать критерии соответствия. Нет никаких причин, чтобы говорить, что деятельность разработчиков программного обеспечения нельзя было стандартизовать. Можно строго регламентировать структуру кода, применяемые инструменты, методики и пр. Можно заставить («кнутом и пряником») разработчика следовать предписаниям. С точки зрения исполнения отдельного проекта экономический эффект будет великолепен. И чем больше похожих проектов, тем выше экономический эффект. Именно это положение и лежит в основе CMM и аналогичных стандартов. Действительно, становится возможным достаточно точный прогноз и сроков, и бюджета, и трудозатрат, и, в целом, себестоимости проекта. Чего же еще может желать руководитель проекта? Наверное, только одного... чтобы каждый последующий проект был «как две капли воды» похож на предыдущий. Но в проектных организациях это лишено смысла, если новый проект является копией предыдущего, то... надо просто скопировать файлы. А если жизнь подбрасывает новые задачи, то стандартизация начинает мешать. Что толку знать, что на решение какой-то другой задачи потребовался месяц, ведь надо знать сколько времени потребуется на решение этой, а не другой, задачи. И чем больше новизны, тем выше неопределенность, тем меньше помощи от стандартов, тем больше вреда от них. Стандарты сохраняют свою полезность только при выполнении рутинных операций. Но в проектном производстве в отличие от промышленного производства при правильной организации работ рутины крайне мало. К сожалению, приемы промышленного производства прямо переносят на проектное производство, без учета специфики последнего.
AlbertGИначе очень проблематично разбираться с кодом другого программиста, другого творца. Ведь многие полагают, что "правильный" код только у них. Объектность и может здесь присутсвовать как стандартКак ни странно, но программисты, которые считают, что правильный код только у них... правы. Понимаю, что это кажется нелепостью, но... это так. Когда-то Тейлор, занимаясь нормированием труда (помните: «научная система выжимания пота»?), отметил странный феномен. Если двух рабочих, не обучая предварительно, поставить на одну и ту же операцию, но так чтобы они не видели друг друга и даже не общались, то со временем у них вырабатываются одинаковые приемы. Схожесть приемов и ритма выполнения операции тем выше, чем более похожи рабочие по своим физическим параметрам, чем более схож их инструмент (оборудование). При этом каждый рабочий сам вырабатывал свои приемы, ничего не зная о приемах своего коллеги. И эти приемы были правильными, с той точки зрения, что они были оптимальны для данных условий работы.
Нет, я совсем не предлагаю ставить перед всеми разработчиками одинаковые задачи, давать им одни и те же инструментальные средства и т.п. Но, по моему мнению, к выработке навыков, приемов надо относится очень серьезно. Все разработчики имеют уникальные навыки и это нормально. Конечно, можно заставить программистов следовать каким-то правилам/стандартам. И при появлении новой проблемы они будут ждать от руководителя проекта новых указаний, новых правил, новых стандартов. И чем далее будет развиваться проект, тем чаще будут возникать вопросы несоответствия принятых стандартов новым задачам и новым условиям. Если проект достаточно сложный, то можно только гадать, что произойдет раньше: проект зайдет в тупик или он все же успеет завершиться.
Переход к разработке на основе семантических моделей имеет свою особенность. Здесь нет необходимости сковывать инициативу и творчество разработчиков, нет необходимости бояться того, что проект превратиться в очередную «вавилонскую башню». Строители вавилонского чуда утратили общий язык и это положило конец строительству. Это не метафора – это суть. Семантическая модель дает разработчикам общий язык, язык смысла. Дайте им возможность общаться на этом языке и общие принципы работы появятся сами собой... из неоткуда. Можно проложить дорожки к институту и закатать их асфальтом, но можно подождать, пока люди проложат наиболее удобный для них путь и только потом класть асфальт. И, что важно, путь пройдет не там, где ходят аккуратные и рассудительные люди. Путь пройдет там, где бегают те, кто постоянно опаздывает на работу, те кто неорганизован и рассеян. При разработке правил и внутренних стандартов можно следовать «умным» книгам, советам «мастеров», можно прокладывать дорожки и заставлять ходить по ним. Но все советы рано или поздно войдут в противоречие с жизнью. Надо следовать жизни, а не советам. И нет в этом ничего сложного, если понимается смысл.
Понимание «объектности», как стандарта, мне кажется неверным. Для меня «объектность» важна, как инструмент моделирования, как средство проецирования моделей на различные предметные области.
AlbertGЕсли же тот же дизайнер делает формы на основе объектов, то он в равной степени мог бы и легко изменить их внешний вид в угоду новому веянию.
Цель объектности для непосредственно программиста вижу в уменьшении числа изменеий кода, для реализаций новых возможностей.
Как пример: сделали возможность задавать какую-то функциональность - фильтр определяемый пользователем, далее продвинутый пользователь уже сам может сконструировать для себя критерии отбора данныхС моей точки зрения, «объектность» хороша там, где она сопряжена с постижением смысла, раскрытием этого смысла с самых разных точек зрения и, наконец, там где она подводит к пониманию композиции.
AlbertG ASUЕсли Тенцер для Вас авторитет, то продолжать разговор не имеет смысла.Я не хотел Вас обидеть. Я просто упомянул его как автора практического решенияВы меня не обидели. Гераклит сказал: «Дорога вверх и дорога вниз – одна и та же дорога». Если мы с Вами идем в разных направлениях, один вверх, а другой вниз, то у нас нет шанса понять друг друга. Один будет говорить о трудностях и красоте восхождения, второй – о сложностях и опасности спуска. Надо ли говорить, если нет возможности понять друг друга?

guest_20040621 ASUВозможности, предоставляемые новыми технологиями, нарастают быстрее, чем формируются и принимаются новые стандартыНапример?Достаточно давно существует возможность построения распределенных слабосвязных систем с высоким уровнем параллелизма (MPP-систем). Но стандартов нет до сих пор. Сейчас делаются попытки разработать GRID, но, во-первых, это еще далеко не то, что нужно/возможно, во-вторых, попытки явно опоздали (лет на 25-30), в-третьих, полезность будущих стандартов еще надо будет доказать.
guest_20040621 ASUПосмотрите в соседних обсуждениях нарекания в адрес SAP, BAAN и пр. С чем связано недовольство? В частности с тем, что стандарты, принятые на этих фирмах, входят в противоречие с потребностями пользователейЗначит, то, что они считают стандартами, таковыми не является. Или имеет кривую реализацию. Для меня SAP, BAAN и прочие монстры не являются эталономРечь не обо мне и не о Вас, а о сотрудниках этих фирм. Для них внутренние стандарты существует и отступление от них карается.
guest_20040621 ASUКаждый человек творец. По крайней мере, я не испытываю недостатка в творческих людяхНе нужно подменять понятия. Меня не интересуют абстрактные творческие наклонности абстрактного человека. Художник? - устраивай персональные выставки, продавай работы, преподавай, - да мало ли как можно зарабатывать на жизнь творчеством. Кодируешь? - продаешь некоторое количество своих знаний по вполне конкретной цене, определяемой наличием аналогичных услуг аналогичных специалистов. Разница не очевидна?Хм... Мне не приходило в голову рассматривать творчество, как... средство зарабатывания на жизнь. Творчество - это, в простом случае, самореализация. Вы случайно не перепутали понятия творца и продавца? (Кстати, и продавец может быть творцом, то есть, реализовывать себя посредством торговли).
guest_20040621 ASUЛюди являются ремесленниками ровно в той мере, в какой их возможности скованы устаревшими стандартами, нормами, правиламиА что мешает людям перестать быть ремесленниками и начать быть творцами? Религия? ;) Нет, наверное, не религия, но вера. Слепая вера в инструкции, предписания, методики. Человеку очень сложно отрешиться от всего того, что раньше регламентировало его жизнь. Лет десять назад в армиях стран НАТО проводились исследования. Казалось, что в армии в значительной части должны быть люди с сильным характером, люди, способные на риск, на принятие решений. Оказалось, что все строго наоборот. Основу армий составляли социально дезориентированные люди, люди со слабым характером, с подавленной волей, неспособные мыслить самостоятельно. Зачем в армии мыслить? Кому там нужен характер? Там нужна слепая вера в приказ, в командира. Представьте, что завтра этих людей "выпустят" в нормальную жизнь. Они будут чувствовать себя брошенными, никому не нужными. Не будет завтрака по расписанию, никто не отдаст распоряжения, все придется делать самому. Это действительно страшно...
guest_20040621 ASUКаков критерий отнесения человека в разряд даунов Вы используете?Обычно - на глазок. Имел бы алгоритм - запатентовал быВ раннем творчестве А. Макаревича была песня "Битва с дураками", она заканчивается словами: Экзюпери говорил, что стоит только начать бороться с горбунами, как станет заметно, что действительно прямоходящих людей очень мало...