Здравствуйте, Sinclair, Вы писали:
S>Я согласен. Вот только за 10 лет этот велосипед никто не сделал.
Ты знаешь, а на практике подобное вобщем то не особенно то и нужно, потому что делать такое можно только для небольших выборок, а небольшие можно и руками обработать.
S>Может, от того что постановка задачи неверна? Вот я и хочу пересмотреть это все.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>>Подходы — нужны. Иначе зачем монстрам развивать свои продукты? S>> Может Net сдвинет эту скалу.
AVK>Java пока не сдвинула.
А надежда теплится. С другой стороны DB 2 тоже Net приаттачивает. Может конкуренция и подстегнет к принципиально другому.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> А надежда теплится. С другой стороны DB 2 тоже Net приаттачивает. Может конкуренция и подстегнет к принципиально другому.
Здравствуйте, Sinclair, Вы писали:
S>>>1. Надо проанализировать существующие системы на предмет отклонения от 11 требований. M>>Это обязательно. Но систем ООБД я не много знаю: чаще всего упоминают Cache, O2, Orion. Вживую не видел ни одного. S>Я видел Versant, сейчас стоит свежепоставленный Cache 5.1 single user. Вообще в списке предполагаемых жертв сейчас S>
Откуда все это берешь? (возьмешь?)
M>>Признаюсь о таком услышал впервые — если можно поподробнее. Если можешь дай пару ссылок на описания. S>Спасибо Мальборо — он рядом положил ссылку.
Посмотрел — по всей видимости Microsoft идет тем же путем, что и в IIS/ASP.NET ("code behind page"). Немного не верится в рост производительности.
M>>Я думаю — для диссера (кандидатского) много приложений не надо. Надо одно, но достойное — желательно с применением к действительно практической задаче. S>Вопрос интересный. Для меня главное — определить место этой технологии среди существующих. А то получается "да здравствует наша ОДБМС — самая быстрая среди нашей ОДБМС!" С этой точки зрения, надо хотя бы один тест провести на поле "хозяев", т.е. RDBMS.
Абсолютно точно. Причем если этот тест будет в нашу пользу — технология уже имеет право на существование. Если нет — не все потеряно. Достаточно доказать, что производительность не будет резко с нижаться при увеличении объемов данных (сам знаешь — "математика в программировании").
Кроме того важен (я бы сказал он самый важный) аспект трудозатрат при реализации решения. "В этом случае на реализацию ушло такое количество ч/м (написано столько миллионов строк кода), а в этом столько то (столько тысяч строк кода)". Вопрос в необходимости и приемлимости нового метода снимется сам собой.
S>Если будет практическое применение, то надо честно показать, чем наша реализация лучше альтернативы (если она, конечно, лучше). С этим вообще беда — мне ни разу не удалось увидеть реализацию коммерческой системы хотя бы на Oracle и MS SQL — чтобы сравнить реальную проихводительность в конкретном случае. Слишком дорого оказывается. А если разрабатывать весь код в "режиме совместимости", то результат получится совершенно нерелевантным. В общем, нужно не просто доказательтво того, что базу Northwind можно наколбасить и в такой системе, а демонстрация преимуществ.
По поводу режима совместимости согласен. Если проект будет серьезный (и работать будет), то можно поискать его аналоги на рынке и попросить производителей расказать о преимуществах их системы и трудоемкости работ по ее созданию.
M>>Когда "наколбасишь" много (может быть с помощью своих аспирантов) — можешь докторскую защитить. S>Да тут хотя бы что-то наколбасить... Гульбарий там собрать... А докторский саквояж мне, если чо, друзья купют.
Хорошие друзья = залог успеха.
M>>О теоретических аспектах — упомянуто у C.Кузнецова в статье на CITForumе (там даже ссылки есть). Вопрос был затронут и здесь. S>Почитаю. Ты, кстати, кинь прямой линк на статью — а то там Кузнецов-то довольно много чего опубликовал.
M>Откуда все это берешь? (возьмешь?)
Пока не знаю Реально — скорее всего для большинства систем добудутся демки.
M>Абсолютно точно. Причем если этот тест будет в нашу пользу — технология уже имеет право на существование. Если нет — не все потеряно. Достаточно доказать, что производительность не будет резко с нижаться при увеличении объемов данных (сам знаешь — "математика в программировании"). M>Кроме того важен (я бы сказал он самый важный) аспект трудозатрат при реализации решения. "В этом случае на реализацию ушло такое количество ч/м (написано столько миллионов строк кода), а в этом столько то (столько тысяч строк кода)". Вопрос в необходимости и приемлимости нового метода снимется сам собой.
Полностью согласен с обоими высказываниями. M>Хорошие друзья = залог успеха. M>здесь M>и M>здесь
Спасибо.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Года два-три назад я плотненько знакомился с ООСУБД. Самой концептуально чистой и полной была Poet (споследствии переименованая в FastObjects). Есть основания полагать, что она таковой и осталась, потому как и темпы развития у нее повыше, чем у конкурентов.
Советую обратить внимание на них в первую очередь.
Что еще интересно, poet до какой-то версии поддерживало odmg (даже 3.0!!!), а затем от этой поддержки отказались. На наш вопрос "Почему?" был ответ — "Из-за слабой эффективности/производительности" .
WC>Года два-три назад я плотненько знакомился с ООСУБД. Самой концептуально чистой и полной была Poet (споследствии переименованая в FastObjects). Есть основания полагать, что она таковой и осталась, потому как и темпы развития у нее повыше, чем у конкурентов. WC>Советую обратить внимание на них в первую очередь. WC>Что еще интересно, poet до какой-то версии поддерживало odmg (даже 3.0!!!), а затем от этой поддержки отказались. На наш вопрос "Почему?" был ответ — "Из-за слабой эффективности/производительности" .
Здравствуйте, Sinclair, Вы писали:
S>Я хочу получить идеальную систему, в которой разработчик бизнес логики пишет свой кусок кода, размечает его атрибутами, которые сообщают остальной системе необходимую информацию, и инсталляет это в сервер. После чего у всех пользователей сервера сразу доступна расширенная функциональность.
Это я так. Увидел краткое описание того, что у нас работает уже полтора года.
Идеала получить не удалось, потому что человеческий фактор и лень этому не очень способствуют
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Morgun, Вы писали:
M>>Реферат я правда не писал — зачли статью про диплом.Английский сдать не так сложно — мне философия труднее далась (сдал на 5 но попотеть пришлось). S>Не, я во-первых физик, а во-вторых — бакалавр выпуска 97го. А философия у нас — халява
S>>>1. Надо проанализировать существующие системы на предмет отклонения от 11 требований. M>>Это обязательно. Но систем ООБД я не много знаю: чаще всего упоминают Cache, O2, Orion. Вживую не видел ни одного. S>Я видел Versant, сейчас стоит свежепоставленный Cache 5.1 single user. Вообще в списке предполагаемых жертв сейчас S>
Интуитивно от успешной ООСУБД ожидается не менее высокая производительность, чем в РСУБД, так как первая должна включать возможности последней как частный, вырожденный случай объектной модели.
Весьма странный вывод. Обычно от реализации частного случая чего-либо ожидается более высокая производительность, чем от реализации общей модели, не правда ли?
P.S. Я не оспариваю преимущества ООБД при решении _определённого_ класса задач (сам когда-то работал с MUMPS), скорее, занудствую по поводу построения фразы
Re[3]: Что означает понятие skills в резюме для работодателя
Интуитивно от успешной ООСУБД ожидается не менее высокая производительность, чем в РСУБД, так как первая должна включать возможности последней как частный, вырожденный случай объектной модели.
A>Весьма странный вывод. Обычно от реализации частного случая чего-либо ожидается более высокая производительность, чем от реализации общей модели, не правда ли?
Возможно, я неудачно построил фразу. Смысл в том, что успешная ООСУБД не должна заставлять платить за то, чем не пользуешься. Если ты скомпилируешь С программу плюсовым компилятором, она не станет работать медленнее.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
допустим в базе 100000 заказов, по примерно 5 товаров в каждом
как быстро можно выбрать первые 10 из них, у которых хотя бы один заказанный товар имел стоимость > 1000
и еще один вопрос: есть ли поддержка версий документов?
чтоб можно было посмотреть историю изменений, откатить назад и т.д.
и соответственно какой-нть механизм публикации данных?
это я думаю — насколько возможно использование данной системы для создания сайтов
да, а как обстоят дела с правами?
как разграничить какие документы кто и где может создавать и что с ними вообще делать?
Re: Реляционное против нереляционного
От:
Аноним
Дата:
19.03.04 19:20
Оценка:
Здравствуйте, Morgun, Вы писали:
M>Проблема вернулась в новом лице после защиты. Новое лицо — документооборот. Хороший документооборот — гибкий документооборот. Формы и состав документов могут меняться во времени и это не должно отражаться на системе в целом.
Форма представления, не важно, на бумаге или на экране, не изменяет сущности понятий. К примеру, твой начальник, как был начальником, так им и останется, а как ты этот факт отобразиш потребителю информации — отдельная история.
M>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют.
Народ ночи не спит, книжки умные про проектирование БД пишет, да все без толку, учись читать правильно.
Если анализ проблемы позволяет выделить 1 или более неизменяемой структуры, стандартно их называют — сущности, и установить связи между ними, то такая проблема разрешима средствами реляционок, и более того, в большинстве случаев реляционная БД будет почти идеальным решением. Экзотические случаи, когда структура информации может кординально меняться от записи к записи, по большей части сводятся к стандартной теории введением некоторой избыточности. Из средств, предназначеных для обработки данных опираясь на структуру каждой конкретной записи, а не всей БД, наиболее на слуху — это XML. (Интересно, а еще что либо подобное есть?)
M>А что думает уважаемое сообщество? Кто имел опыт разработки с использованием XML и Объектно Ориентированных БД поделитесь опытом и ощущениями, пожалуйста.
Сорри за глупый вопрос, а что такое Объектно Ориентированные БД?
Здравствуйте, Аноним, Вы писали:
А>Форма представления, не важно, на бумаге или на экране, не изменяет сущности понятий. К примеру, твой начальник, как был начальником, так им и останется, а как ты этот факт отобразиш потребителю информации — отдельная история.
Спор не о внешнем предствлении, a о внутреннем. Начальник останется начальником. Документ останется документом, но состав документа может пояеняться.
Совершенно верно, Форма представления не определяет сущность — сущность определяет состав формы представления. А что если сущность может поменяться во времени? У нас это так. В РСУБД — ответ обычно в изменении структуры БД.
M>>Мое личное мнение — чисто реляционная БД не сможет обеспечить должной гибкости. Внутри нашего отдела АСУ не все разделяют это мнение разделяют. А>Народ ночи не спит, книжки умные про проектирование БД пишет, да все без толку, учись читать правильно.
Прочел и не одну — диссер пишу.
А>Если анализ проблемы позволяет выделить 1 или более неизменяемой структуры, стандартно их называют — сущности, и установить связи между ними, то такая проблема разрешима средствами реляционок, и более того, в большинстве случаев реляционная БД будет почти идеальным решением.
А кто спорит?
А> Экзотические случаи, когда структура информации может кординально меняться от записи к записи, по большей части сводятся к стандартной теории введением некоторой избыточности.
Что имелось в виду под стандартной теорией?
А> Из средств, предназначеных для обработки данных опираясь на структуру каждой конкретной записи, а не всей БД, наиболее на слуху — это XML. (Интересно, а еще что либо подобное есть?)
А структура записи не как не относится к структуре БД? А какже тогда 2НФ?
А>Сорри за глупый вопрос, а что такое Объектно Ориентированные БД?
Почитайте хотя бы на CitForume.
Re[3]: Реляционное против нереляционного
От:
Аноним
Дата:
20.03.04 09:22
Оценка:
Здравствуйте, Morgun, Вы писали:
M>Спор не о внешнем предствлении, a о внутреннем. Начальник останется начальником. Документ останется документом, но состав документа может пояеняться. M>Совершенно верно, Форма представления не определяет сущность — сущность определяет состав формы представления. А что если сущность может поменяться во времени? У нас это так. В РСУБД — ответ обычно в изменении структуры БД.
Когда я писал в первый раз, я всео лишь хотел сказать: Ни кто не утверждал, что РСУБД — решение всех проблем. Вы один из многих, кому довелось сталкнуться с ситуацией, когда это не работает. Распространеннось реляционных БД означает только то, что большинство задач укладываются в схему сущностей и отношений. Для остальных — всегда есть XML.
M>Что имелось в виду под стандартной теорией?
Теория, опираясь на которую строят реляционные БД.
В грубом приближении:
1. Анализируем возможные запросы к будущей системе, и групируем атрибуты в одну и более сущностей (Это не будут сущности в том смысле, к которому привыкли разработчики реляционок — потому что выбор количества таких атрибутов и их групировка в сущности в общем-то условны).
2. Устанавливаем связи между нашими псевдосущностями. (Здесь и возникает избыточность)
3. Атрибуты, не отнесенные ни к одной сущности храним в таблице вида: id, rec_id, attr_type, attr_value.
Далее можем использовать средства, ориентированные на РСУБД. Недостаток такой схемы — слишком медленно идет выборка по атрибутам не вошедшим ни в одну из сущностей.
M>А структура записи не как не относится к структуре БД? А какже тогда 2НФ?
А разве это не относится к реляционной модели?
Здравствуйте, Аноним, Вы писали:
А>Когда я писал в первый раз, я всео лишь хотел сказать: Ни кто не утверждал, что РСУБД — решение всех проблем. Вы один из многих, кому довелось сталкнуться с ситуацией, когда это не работает. Распространеннось реляционных БД означает только то, что большинство задач укладываются в схему сущностей и отношений. Для остальных — всегда есть XML.
Вот и хотелось бы выяснить где граница между задачами, где РСУБД применимы, а где нет. И какие подходы применимы за этой границей (кроме XML). Какие инструменты уже есть. Какие идеи есть, но еще не реализованы.
M>>Что имелось в виду под стандартной теорией? А>Теория, опираясь на которую строят реляционные БД.
Это просто неточность в формулировке была — я не сразу понял, что имеется в виду теория РСУБД — вот и уточнил.
M>>А структура записи не как не относится к структуре БД? А какже тогда 2НФ? А>А разве это не относится к реляционной модели?
Относится. НФ выработаны для реляционной модели. Я о записях.
