На сайте ведутся работы Программа для картотеки с архитектурой БД Сычевых | ТРИЗ - РТВ - ТРТЛ | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Все категории » ТРИЗ - РТВ - ТРТЛ » Идеализация структуры данных. Идеальная функция (приложение ТРИЗ к IT)

Программа для картотеки с архитектурой БД Сычевых

Ваши данные (просмотреть)
в избранные темы
Политика конфиденциальности

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
Создать аналогичное обсуждение...

Авторы

Скрыть / Показать
2017-11-14 09:43:19
Карточный Домик » Всем
Здравствуйте, недавно товарищи Сычевы Сергей и Александр выложили в паблик прорывную легковесную архитектуру базы данных, скажем же им за это огромное спасибо, их имена запишут на скрижалях истории.

Нуждаюсь в программе для ведения картотеки, и хочу использовать эту архитектуру без затруднений чтобы она органично вписалась в дизайн программы. Что можно здесь применить? Сейчас я рассматриваю libreoffice base для этой задачи. Могу написать свою программу, но не хочу изобретать велосипед. Картотеки тут должны быть у каждого второго.

Новая архитектура подкупает возможностью легко и просто формуляры разные делать. Обычные программы имеют обычно лишь теги и на том всё.
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2017-11-14 10:18:24
Редакция » Карточный Домик
Уважаемый Коллега!

С 23-го января по 27 февраля 2018 пройдёт онлайн-стажировка во время которой Вы сможете реализовать Ваш замысел. Её программа, условие участия и расписание встреч будут опубликованы в ближайшие дни. Следите за новостями. Или можете подписаться (меню внизу экрана).

Спасибо,
Ответить Сообщение для всех [Нет ответов на это сообщение]
2017-11-16 11:43:05
Сергей В. Сычёв » Карточный Домик
Уважаемый Коллега!

Вы используете libreoffice на Linux?

Спасибо,
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2017-11-17 01:53:59
Карточный Домик » Сергей В. Сычёв
На windows, в планах переезд на Linux но пока что этого не случилось. Идеальным будет кроссплатформенное решение.

Если Ваш вопрос связан с тем что Ваше ядро написано на python, то на windows я готов поставить python и все необходимые модули, и на Linux тоже.

И раз Вы уже здесь позвольте задать вопросы по архитектуре, поскольку я не обнаружил для их обсуждения отдельно выделеной темы:
  1. Сколько времени заняла разработка с нуля?
  2. Есть ли для текущей архитектуры контексты применения, при которых её лучше не использовать? Обычно технологии имеют спект применения где они наиболее уместны, Ваша архитектура выглядит универсальной.
  3. Планируется ли масштабная рекламная компания Вашей архитектуры? Например на профессиональных конференциях баз данных. Ведь если её утащит к себе тот же facebook посредством своих инженеров и сэкономит этим кучу денег то это даст сильнейший импульс к её популяризации, её начнут внедрять на каждом углу.
  4. Есть ли ещё куда улучшать архитектуру или потолок окончательно достигнут?
  5. Вы использовали достаточно сильные ходы, если ли у Вас другие наработки в области IT решающие фундаментальные проблемы? И если есть, то когда и при каких условиях/обстоятельствах с ними можно ознакомиться.

 

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

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2017-11-17 17:44:13
Сергей В. Сычёв » Карточный Домик
Добрый день!

Если Ваш вопрос связан с тем что Ваше ядро написано на python, то на windows я готов поставить python и все необходимые модули, и на Linux тоже.

Вам не надо ставить python. Ядро хоть и написано на серверном языке, но закомпилировано. Плюс идея заключается в том, что Ваша база (равно и Ваше приложение) находятся у Вас, а "ядро" - в "облаке".

Сколько времени заняла разработка с нуля?

Время "нетто" - чистых 15 человеко х лет. С учётом времени на разработку и отработку методики решения задач и внутреннюю теорию организации данных и потом на - собственно - программирование. 

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

Видите ли, это как "арифметика". Наверное, арифметика не помогает решать драмы в личной жизни и многое другое.

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

Я не понял. Вы пишете, что нашей разработке на пользу, если её утащит facebook? Или Вы пишете, что в facebook работают воры? Или Вы пишете, что воровать - хорошо? Или Вы пишете иное? 
 
Есть ли ещё куда улучшать архитектуру или потолок окончательно достигнут?

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

Есть. Следите за новостями и Форумом, записывайтесь на стажировки.

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

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

С Уважением,


Ответить Сообщение для всех [Показать все ответы на это сообщение]
2017-11-18 06:09:42
Карточный Домик » Сергей В. Сычёв
Большое спасибо за детальные ответы.

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

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

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

Ещё возникло немного вопросов:
  1. Ваше ядро написано на go?
  2. Ваших клиентов не смущает что фактически элемент бизнеса начинает быть завязан на uptime Вашего сервера на котором работает ядро? И на Вас в частности. Если что-то пойдёт не так (Вас взломают, ремонтные работы в ДЦ, роскомнадзор заблокирует IP, проблемы с интернетом у клиентов, итд), то бизнес начинает терять деньги поскольку ядро становится не доступно. Да Вы решаете часть проблем в плане хранения данных на стороне клиента и тем самым Вы не есть чистое облако, но привязка к Вам достаточно чувствительная.
  3. Возможно ли малыми силами и без высоких накладных расходов сделать так чтобы Ваша архитектура могла содержать всю информацию строго в шифрованном виде, и программа-клиент удалённо подключалась к базе и информация расшифровывается по ключу лишь на стороне клиента?
  4. Когда Вы разрабатывали архитектуру то наверное изучали уже имеющиеся варианты решения проблемы, какое из них по Вашему мнению наиболее близко приблизилось к Вашему?
  5. Чем обусловлено такое долгое время разработки? 15 лет это же для IT целый век!
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2017-11-18 14:45:19
Сергей В. Сычёв » Карточный Домик
Добрый день!

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

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

Если же Вы пишете об архитектуре приложений, то это Вы можете реализовывать как показано на первом вебинаре.

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

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

Ваших клиентов не смущает что фактически элемент бизнеса начинает быть завязан на uptime Вашего сервера на котором работает ядро?

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

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

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

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

Бизнес также привязан к Apple, Google, Amazone, Microsoft, Oracle и т.д. Сотни тысяч компаний отправляют данные в "облака", имеют несоизмеримо большие риски (по сравнению с теми, о которых пишете Вы), и у них нет выбора. Мы же этот выбор бизнесу предоставляем. Мы создали решение, которое позволяет получать облачные сервисы, не храня там данных (если не хочется их там хранить). Это громадный прыжок вперёд. Это точно лучше, чем то, что есть.

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

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

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

Немало EAV-решений были близки. Но из-за того, что "имена" не были вынесены за пределы базы качественного прорыва не произошло.

Чем обусловлено такое долгое время разработки? 15 лет это же для IT целый век!

Ну, это же 15 человеко-лет.

C Уважением,
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2017-11-18 18:54:41
Михаил Куликов » Всем

Здравствуйте! Спасибо Редакции за оперативные ответы.

Позвольте передать вопрос от моего руководства, связанный с опытом "зависимости" от Adobe. Изначально Adobe продавал "вечные" лицензии на свое ПО (ПО как товар). Многие клиенты построили свои бизнес-процессы, основываясь на таких "вечных" лицензиях. А затем Adobe "бросил" старые версии; новые версии продавались только по подписке (ПО как услуга) и цены значительно выросли.

Конечно, на это были свои причины и закономерности. И теперь так многие делают. Собственно, возражение руководства: свяжемся с подпиской, а потом цены взлетят. Что можно ответить?

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2017-11-18 19:15:59
Редакция » Михаил Куликов
Уважаемый Михаил!

Если Вы пишете программы не для себя, а для Ваших Клиентов, то на этом можно и зарабатывать. Получили ли документ о франшизе технологий, созданных в "TRIZ-RI Group"?

Спасибо,
Ответить Сообщение для всех [Нет ответов на это сообщение]
2017-11-26 04:30:26
Валерий Серов » Сергей В. Сычёв
Если написать ядро целиком на SQL как хранимую процедуру (функцию), то в производительности не потеряем?
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2017-11-27 17:49:19
Александр Сычёв » Валерий Серов
Уважаемый Валерий!

Отвечу, поскольку о хранимых процедурах уже писал в соседней ветке. Касательно быстродействия не прокомментирую, но поясню, почему мы их не используем. Ниже цитата из обсуждения по ссылке + ещё несколько слов.

"Если хранимые процедуры использовать, тогда при работе с разными СУБД нам придется учитывать их специфику и "подгонять" процедуры под них. У Клиентов могут работать:

а) разные реляционные БД (SQL-сервер, Firebird, Sqlite, Oracle, PostgreSQL, MySQL и др.); 

б) NoSQL , файловые БД - тоже разные. 

Более того, вдруг проект у Клиента "переедет" на другую СУБД, а диалекты процедурных языков разных СУБД могут быть несовместимы. См., например. 

Даже, если и насобирать заранее "заготовок" под каждую, что мы будем делать, если понадобится обновить Составитель Запросов или Диспетчер? А зачем нам это всё (при "сычёвской-то структуре", которой вообще всё равно какая там база). Если можно об этом не думать, то лучше и не думать.

С другой стороны, и сам проект тоже развивается. Получается, если нужно будет сделать обновление у Клиента, то (при хранимых процедурах) надо либо писать скрипты, либо связываться с Клиентом и объяснять его админу, что и как сделать. Скорее всего, никто ничего делать не будет.

Если же Составитель запросов и Диспетчер изолированы от базы, то они будут работать независимо от её типа. А обновление ядра будет заключаться в замене файла на новую версию". (Конец цитаты).

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

Спасибо,
Ответить Сообщение для всех [Нет ответов на это сообщение]


Яндекс.Метрика