Мир состоит из коллекций объектов, а не из прямоугольных таблиц.
Почему, я не знаю.
Свойства объекта удобнее хранить как документ, а не как строчку в таблице.
Если бы замечательный артефакт «1С» имел документо-ориентированную основу,
доработка 1С не была бы самой востребованной работой для программиста в России.
Это мое скромное мнение.
С трудом представляю, как мне это все настроить на моем ноутбуке под win7/HomeEdition.
Есть решения попроще?
Можете посоветовать smtp подобрее в плане спама?
smtp.mail.ru я проверил — то же самое.
Как обойти защиту от спама?
У меня в базе 600 студентов, периодически я им отправляю материалы.
Простенькая CRM умеет делать рассылку, надо только прописать smtp-сервер.
Указал свой логин на Яндексе, smtp.yandex.ru:465 и сумел отправить 200 писем в сутки.
А если больше, Яндекс дает ошибку «подозрение на спам». При этом в заголовке и в теле письма есть Имя-Отчество (т.е. письма чуть-чуть разные).
Ладно, смирился, но через какое-то время Яндекс стал ругаться после 100 писем.
Попробовал smtp.googlemail.com:587/TLS
После 50 писем получил ошибку «Перейдите в режим веб-интерфейса».
Что посоветует уважаемый All?
И обратите внимание, что уже два моих конкретных технических замечания к предлагаемому вами решению вы проигнорировали.
Извиняюсь, я не старался выбрать вопросы поудобнее.
1. Про индексирование. Документы хранятся в таблице из 5 столбцов: uuid, xcreated, xname, xvalue, xmodified.
uuid, xname, xvalue — индексированы
2. Повторите, плиз, вопрос, — вопросов много, среди них есть риторические, т.е. не требующие ответа (зачем мне демонстрировали систему?).
Про бизнес-аналитику в идеале Вы правы. Только в жизни представитель заказчика не всегда понимает, что он хочет в результате получить.
Но обсуждать эту тему лучше не со мной. Я специалист по ДП и не планирую строить модели в других областях.
Документо-ориентированные БД можно противопоставлять реляционным или объектно-ориентированным; но нельзя противопоставлять БД — ORM, потому что ORM — это уже механизм работы с БД.
Конечно, я сравнивал ДОБД с ОРМ.
А в реляционной БД было бы 100 тыс. Разница в два порядка (и да, эта разница сказывается на скорости и месте).
Места ДОБД, возможно, займет меньше. Если в документе заполнено 5 полей из 50 возможных, в ДОБД пустых полей просто не будет, а в РСУБД они будут, но пустые.
Я изучал возможность построения базы на ОРМ, но забраковал эту идею. Объекты в ОРМ должны быть статичны, хранение в одной таблице объектов разных классов приводит тому, что таблиц становится несколько. В результате все не гибко, не быстро и не удобно.
Вы, кажется, не поняли: я говорю о предлагаемом вами подходе, когда в БД хранятся правила/скрипты.
В плане версий: скрипты могут хранятся в виде файлов, а в базу загружаться по команде. Верификация даже проще — не надо перегружать сервер.
Если ваше решение применимо только для СЭД, так и скажите.
Так и говорю: мое решение применимо только для СЭД. Только СМК я тоже считаю СЭД. И CRM тоже СЭД. И bug tracking — тоже СЭД. А бухгалтерия — это не СЭД? Скажите главбуху, что ее работа не связана с документами и внимательно проследите за реакцией.
я спрашиваю как упоминаемое вами документо-ориентированное решение поверх SQLite обеспечивает производительность, сопоставимую с чисто реляционными или чисто документо-ориентированными решениями.
SQLite годится для локала, для больших систем другие серверы.
Производительность вещь лукавая. Есть простой поиск, есть сложный, есть время открытия, время сохранения, время связывания объектов и пр.
Для СЭД наше решение оказалось наиболее удачным. Оно обеспечило даже лучшую производительность, чем РСУБД.
Структуру базы я описал, индексы тоже. Есть еще коллекции (виды) документов. Больше ничего нет. Можно считать, что у программистов РСУБД руки кривые, а можно, что архитектура ДОБД более эффективна. Я не из головы беру сравнения: была конкретная СЭД на ДОБД, заменили на СЭД на РСУБД, — стало хуже, была другая конкретная СЭД на РСУБД, заменили на СЭД на ДОБД, — стало лучше.
Странный вопрос. Я 17 лет занимаюсь делопроизводством и не стремлюсь в архитекторы.
Мне в очень солидной фирме демонстрировали модель БД для СЭД на Rational Rose размером со стену.
Архитектор БД умный интеллигентный профессионал, вот только СЭД у них получилась полупрофессиональная.
Потому что он не был делопроизводителем, а артифакты рисовались на основе бесед с секретаршами.
Я представляю их плюсы и минусы. — Плюсы и минусы по сравнению с чем?
Странный вопрос. Если бы я написал «Я знаю их возможности», вопроса бы не возникло?
Это не архитектура, это бизнес-анализ.
Бизнес-анализ определяет архитектуру, я считаю, эти вещи нельзя делить. Архитектор должен знать бизнес процессы.
Если он просто соединит квадратики стрелочками, получится то, что я описал выше.
В чем выражается более высокая эффективность? Более высокая эффективность по сравнению с чем?
Странный вопрос. Абзац описывает, что объекты с неопределенным набором атрибутов удобнее хранить в ДОБД по сравнению с ОРМ.
Сова — это частный пример решения, которые вы озвучиваете в статье. А я говорю о всем подходе целиком.
управление версиями за счет перевода измененных полей в историю, верификация нужна только для проверки связанных объектов.
Есть агент, который это делает.
А сколько у вас строк в этих таблицах?
Не много: 5-10 млн
Я говорил о сложных.
С СЭД работают 1000 человек. И 99.9% запросов простые. Это не теория, это опыт.
В РСУБД простые запросы выполняются не просто медленнее, а значительно медленнее, чем в ДОБД (я говорю о трех российских СЭД, с которыми я работал).
Сложные запросы — это отчетность, которая может собираться и 5 минут, и 10.
Нельзя заменить Lotus Notes на Oracle, это решения разного уровня.
Странное замечание. Почему нельзя? Взяли и заменили. Была СЭД на ЛН, стала на Оракл. Было быстро, стало медленно.
И я вовсе не считаю, что у программистов руки кривые или архитектор не так квадратики расставил и не так стрелочки нарисовал.
Я знаю 3 (три) популярные СЭД на РСУБД и все 3 ведут себя одинаково.
Если вы делопроизводитель, а не программист, и не архитектор...
Я считаю, что именно делопроизводитель должен определять архитектуру системы. Для этого он должен ориентироваться в существующих технологиях.
Если спросить программистов: «Что главное в СЭД?» — большинство ответит, что главное — это электронная подпись и электронное согласование.
Делопроизводитель эти задачи поставит по важности на 5-6 место. К сожалению большинство СЭД на рынке проектировались программистами.
Я не программировал в ОРМ, но читал документацию по Hibernate и Django и представляю их плюсы и минусы.
Когда модель статична, для нее можно прописать и оптимизировать сложные запросы, и все будет прекрасно работать.
Но когда состав свойств объекта может меняться, когда объект во время жизненного цикла может обрасти новыми свойствами,
более эффективно использовать ДОБД.
каким образом предлагаемое вами решение интегрируется с системами управления версиями и системами автоматической верификации?
В Сове никак не интегрируется.
каким образом при создании документо-ориентированной БД на SQLite (или любой другой реляционной БД) обеспечивается необходимая и достаточная для крупных решений производительность при сложных запросах?
Поля индексируются, каждый запрос по одной таблице, таблицы относительно небольшие (в одной таблице как правило меньше 100 000 документов). Если нужна выборка по нескольким таблицам, будет работать медленнее, но таблицы можно раскидать по нескольким серверам.
В СЭД такой подход более эффективен, потому что большинство запросов простые, плюс пользователю не надо искать по всей базе.
В КУГИ СПб после замены ДОБД (LN) на РСУБД (Oracle) делопроизводители жаловались, что работать стало медленнее.
Моя роль в статье «Печальное будущее толстых клиентов...» следует из подписи: Делопроизводитель.
Я хорошо знаю, что требуется от системы, и могу это объяснить программистам. По-этому я и писал «мы».
Второй вопрос я не совсем понял. Я (как любой человек) иногда рассуждаю на совершенно разные темы, даже на те, где моей роли нет никакой.
Если Вы о фрагментах кода, — то их написал я специально для статьи. Ни в RSF, ни в Сове таких фрагментов нет. Правила с похожими названиями есть,
но они означают совсем другое.
Грешен, я имею отношение к Результат, но фреймворк писал не я (и статью в песочнице тоже не я).
Сова — это моя авторская работа, я написал ее для жены и выложил в сеть на сайте-страничке crm-sova.ru (там, к слову, об ООО «Результат» ни слова).
Когда Результат предложил выложить Сову на своем сайте, я был не против. Вот так Сова стала «официально предлагаемой».
Авторских прав я не заявлял, а к официальному сайту доверия больше.
Я извиняюсь за то, что в моей статье оказалась реклама Совы, а Сова в свою очередь оказалась на коммерческом сайте, но прошу учесть,
что Сова продукт некоммерческий. Как правило, бесплатные CRM в чем-то ограничены, их задача склонить пользователя купить платную версию.
С Совой иначе: ни я, ни Результат не предлагают платную версию CRM (ее просто нет).
По моему скромному мнению, ООБД и ДОБД — это одно и то же.
Это БД, в которой могут храниться объекты с произвольным набором свойств.
В ДОБД такие объекты называют документами, в ООБД — объектами.
Известная аналогия ДОБД с лесом, деревьями, сучьями и листиками мне не нравится,
потому что наборы документов в ней почему-то называют коллекциями, а должны называть гербариями.
Увы, это заблуждение.
Модель определяется тем, кто ее строит, его пониманием задачи.
для одной задачи подходит одна модель, а для другой — другая
об этом и речь. О том, что документо-ориентированные задачи загоняют в реляционные таблицы.
Почему, я не знаю.
Свойства объекта удобнее хранить как документ, а не как строчку в таблице.
Если бы замечательный артефакт «1С» имел документо-ориентированную основу,
доработка 1С не была бы самой востребованной работой для программиста в России.
Это мое скромное мнение.
При всем уважении, здесь статью обсуждают, а не автора
Студент предложил свой smtp-сервер, обещал не антиспамить
Есть решения попроще?
Можете посоветовать smtp подобрее в плане спама?
smtp.mail.ru я проверил — то же самое.
У меня в базе 600 студентов, периодически я им отправляю материалы.
Простенькая CRM умеет делать рассылку, надо только прописать smtp-сервер.
Указал свой логин на Яндексе, smtp.yandex.ru:465 и сумел отправить 200 писем в сутки.
А если больше, Яндекс дает ошибку «подозрение на спам». При этом в заголовке и в теле письма есть Имя-Отчество (т.е. письма чуть-чуть разные).
Ладно, смирился, но через какое-то время Яндекс стал ругаться после 100 писем.
Попробовал smtp.googlemail.com:587/TLS
После 50 писем получил ошибку «Перейдите в режим веб-интерфейса».
Что посоветует уважаемый All?
Извиняюсь, я не старался выбрать вопросы поудобнее.
1. Про индексирование. Документы хранятся в таблице из 5 столбцов: uuid, xcreated, xname, xvalue, xmodified.
uuid, xname, xvalue — индексированы
2. Повторите, плиз, вопрос, — вопросов много, среди них есть риторические, т.е. не требующие ответа (зачем мне демонстрировали систему?).
Про бизнес-аналитику в идеале Вы правы. Только в жизни представитель заказчика не всегда понимает, что он хочет в результате получить.
Но обсуждать эту тему лучше не со мной. Я специалист по ДП и не планирую строить модели в других областях.
Конечно, я сравнивал ДОБД с ОРМ.
Места ДОБД, возможно, займет меньше. Если в документе заполнено 5 полей из 50 возможных, в ДОБД пустых полей просто не будет, а в РСУБД они будут, но пустые.
Я изучал возможность построения базы на ОРМ, но забраковал эту идею. Объекты в ОРМ должны быть статичны, хранение в одной таблице объектов разных классов приводит тому, что таблиц становится несколько. В результате все не гибко, не быстро и не удобно.
В плане версий: скрипты могут хранятся в виде файлов, а в базу загружаться по команде. Верификация даже проще — не надо перегружать сервер.
Так и говорю: мое решение применимо только для СЭД. Только СМК я тоже считаю СЭД. И CRM тоже СЭД. И bug tracking — тоже СЭД. А бухгалтерия — это не СЭД? Скажите главбуху, что ее работа не связана с документами и внимательно проследите за реакцией.
SQLite годится для локала, для больших систем другие серверы.
Производительность вещь лукавая. Есть простой поиск, есть сложный, есть время открытия, время сохранения, время связывания объектов и пр.
Для СЭД наше решение оказалось наиболее удачным. Оно обеспечило даже лучшую производительность, чем РСУБД.
Структуру базы я описал, индексы тоже. Есть еще коллекции (виды) документов. Больше ничего нет. Можно считать, что у программистов РСУБД руки кривые, а можно, что архитектура ДОБД более эффективна. Я не из головы беру сравнения: была конкретная СЭД на ДОБД, заменили на СЭД на РСУБД, — стало хуже, была другая конкретная СЭД на РСУБД, заменили на СЭД на ДОБД, — стало лучше.
Странный вопрос. Я 17 лет занимаюсь делопроизводством и не стремлюсь в архитекторы.
Мне в очень солидной фирме демонстрировали модель БД для СЭД на Rational Rose размером со стену.
Архитектор БД умный интеллигентный профессионал, вот только СЭД у них получилась полупрофессиональная.
Потому что он не был делопроизводителем, а артифакты рисовались на основе бесед с секретаршами.
Странный вопрос. Если бы я написал «Я знаю их возможности», вопроса бы не возникло?
Бизнес-анализ определяет архитектуру, я считаю, эти вещи нельзя делить. Архитектор должен знать бизнес процессы.
Если он просто соединит квадратики стрелочками, получится то, что я описал выше.
Странный вопрос. Абзац описывает, что объекты с неопределенным набором атрибутов удобнее хранить в ДОБД по сравнению с ОРМ.
управление версиями за счет перевода измененных полей в историю, верификация нужна только для проверки связанных объектов.
Есть агент, который это делает.
Не много: 5-10 млн
С СЭД работают 1000 человек. И 99.9% запросов простые. Это не теория, это опыт.
В РСУБД простые запросы выполняются не просто медленнее, а значительно медленнее, чем в ДОБД (я говорю о трех российских СЭД, с которыми я работал).
Сложные запросы — это отчетность, которая может собираться и 5 минут, и 10.
Странное замечание. Почему нельзя? Взяли и заменили. Была СЭД на ЛН, стала на Оракл. Было быстро, стало медленно.
И я вовсе не считаю, что у программистов руки кривые или архитектор не так квадратики расставил и не так стрелочки нарисовал.
Я знаю 3 (три) популярные СЭД на РСУБД и все 3 ведут себя одинаково.
Я считаю, что именно делопроизводитель должен определять архитектуру системы. Для этого он должен ориентироваться в существующих технологиях.
Если спросить программистов: «Что главное в СЭД?» — большинство ответит, что главное — это электронная подпись и электронное согласование.
Делопроизводитель эти задачи поставит по важности на 5-6 место. К сожалению большинство СЭД на рынке проектировались программистами.
Я не программировал в ОРМ, но читал документацию по Hibernate и Django и представляю их плюсы и минусы.
Когда модель статична, для нее можно прописать и оптимизировать сложные запросы, и все будет прекрасно работать.
Но когда состав свойств объекта может меняться, когда объект во время жизненного цикла может обрасти новыми свойствами,
более эффективно использовать ДОБД.
В Сове никак не интегрируется.
Поля индексируются, каждый запрос по одной таблице, таблицы относительно небольшие (в одной таблице как правило меньше 100 000 документов). Если нужна выборка по нескольким таблицам, будет работать медленнее, но таблицы можно раскидать по нескольким серверам.
В СЭД такой подход более эффективен, потому что большинство запросов простые, плюс пользователю не надо искать по всей базе.
В КУГИ СПб после замены ДОБД (LN) на РСУБД (Oracle) делопроизводители жаловались, что работать стало медленнее.
Я хорошо знаю, что требуется от системы, и могу это объяснить программистам. По-этому я и писал «мы».
Второй вопрос я не совсем понял. Я (как любой человек) иногда рассуждаю на совершенно разные темы, даже на те, где моей роли нет никакой.
Если Вы о фрагментах кода, — то их написал я специально для статьи. Ни в RSF, ни в Сове таких фрагментов нет. Правила с похожими названиями есть,
но они означают совсем другое.
Сова — это моя авторская работа, я написал ее для жены и выложил в сеть на сайте-страничке crm-sova.ru (там, к слову, об ООО «Результат» ни слова).
Когда Результат предложил выложить Сову на своем сайте, я был не против. Вот так Сова стала «официально предлагаемой».
Авторских прав я не заявлял, а к официальному сайту доверия больше.
Я извиняюсь за то, что в моей статье оказалась реклама Совы, а Сова в свою очередь оказалась на коммерческом сайте, но прошу учесть,
что Сова продукт некоммерческий. Как правило, бесплатные CRM в чем-то ограничены, их задача склонить пользователя купить платную версию.
С Совой иначе: ни я, ни Результат не предлагают платную версию CRM (ее просто нет).
Это БД, в которой могут храниться объекты с произвольным набором свойств.
В ДОБД такие объекты называют документами, в ООБД — объектами.
Известная аналогия ДОБД с лесом, деревьями, сучьями и листиками мне не нравится,
потому что наборы документов в ней почему-то называют коллекциями, а должны называть гербариями.