ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Клиентское приложение - Сервер Приложений - СУБД
155 сообщений из 155, показаны все 7 страниц
  все  
Клиентское приложение - Сервер Приложений - СУБД
    #39473558
Дядька с усами и часами
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дядька с усами и часами
Участник
Здравствуйте, уважаемые программисты!
Прошу поделиться соображениями вот о чём.
Пишу клиентские desktop приложения (C# WinForms) под Виндовс для работы с Базами Данных (речь о веб-приложениях пока не ведём, обсуждаем только desktop).
Код: c#
1.
Клиентское приложение <----> СУБД

Напишите, какие по вашему мнению существуют преимущества у трёхзвенной схемы:
Код: c#
1.
Клиентское приложение <----> Сервер Приложений <----> СУБД

Также буду рад прочесть о случаях из вашей практики в пользу той или иной точки зрения.
Спасибо.
...
Рейтинг: 0 / 0
17.06.2017, 10:56
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39473885
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Дядька с усами и часами,

на среднем слое можно реализовать какую-то бизнес логику, не на расширениях SQL.

Кроме этого, если нужно иногда задействовать какие-то другие компоненты или службы, например, послать с сервера сообщение по электронной почте или что-то в этом роде, из кода в базе данных на SQL это бывает достаточно трудно сделать. А со среднего звена никаких проблем. Вообще, если управление попадает в код на SQL, из него потом трудно выбраться куда-то ещё, кроме клиента СУБД.
...
Рейтинг: 0 / 0
19.06.2017, 02:29
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39473924
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Дядька с усами и часами....
Напишите, какие по вашему мнению существуют преимущества у трёхзвенной схемы
....
если как у индусов, оплата по кол-ву строк кода==> можно больше написать кода ==> выше заработок
...
Рейтинг: 0 / 0
19.06.2017, 09:08
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39473937
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
MasterZivна среднем слое можно реализовать какую-то бизнес логику, не на расширениях SQL.
особенно что касается разграничения прав доступа
...
Рейтинг: 0 / 0
19.06.2017, 09:35
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39473944
Дядька с усами и часами
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дядька с усами и часами
Участник
Leonid Kudryavtsevможно больше написать кода ==> выше заработокможет быть ещё какие-то аргументы?
...
Рейтинг: 0 / 0
19.06.2017, 09:52
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39473946
Дядька с усами и часами
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дядька с усами и часами
Участник
ИзопропилMasterZivна среднем слое можно реализовать какую-то бизнес логику, не на расширениях SQL.
особенно что касается разграничения прав доступанапример? на среднем звене организовать свою систему юзеров-ролей-паролей, при том, что сам Сервер Приложений ломится в БД от имени одной и той же учётки? вы это имеете ввиду?
...
Рейтинг: 0 / 0
19.06.2017, 09:55
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39473980
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
schi
Участник
Дядька с усами и часамиЗдравствуйте, уважаемые программисты!
Прошу поделиться соображениями вот о чём.
Пишу клиентские desktop приложения (C# WinForms) под Виндовс для работы с Базами Данных (речь о веб-приложениях пока не ведём, обсуждаем только desktop).
Код: c#
1.
Клиентское приложение <----> СУБД

Напишите, какие по вашему мнению существуют преимущества у трёхзвенной схемы:
Код: c#
1.
Клиентское приложение <----> Сервер Приложений <----> СУБД

Также буду рад прочесть о случаях из вашей практики в пользу той или иной точки зрения.
Спасибо.

А что, если слова начинать с заглавной буквы, это им дополнительный вес придает ? Просто интересно...
...
Рейтинг: 0 / 0
19.06.2017, 10:36
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474010
просто я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
просто я
Гость
Дядька с усами и часаминапример? на среднем звене организовать свою систему юзеров-ролей-паролей, при том, что сам Сервер Приложений ломится в БД от имени одной и той же учётки? вы это имеете ввиду?
ну "свою систему юзеров-ролей-паролей" это ваше дело, но вот сбором "в одну кучку"/расчетами/пересчетами каких-то данных из разных систем и БД, чтоб не терять время на "...кучку..." на клиенте, а отдать ему сразу - можно наверное...
...
Рейтинг: 0 / 0
19.06.2017, 11:08
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474086
alexk123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexk123
Участник
Сервер приложений позволяет много чего:
...
Рейтинг: 0 / 0
19.06.2017, 13:00
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474092
alexk123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexk123
Участник
- организовать общие кэши, используя другую бесплатную базу типа кеу-value и т.п.
- минимизировать количество сессий на СУБД (важно, если лицензирование ведется по количеству сессий), требования к серверу СУБД становятся меньшими (как за счет меньшего количества сессий, так и переноса логики)
- появляются возможности масштабирования горизонтального (когда ERP вырастет до нескольких тысяч пользователей)
- ну и возможности языков типа JAVA и т.п., которые используются на серверах приложений, гораздо шире, чем языки СУБД
...
Рейтинг: 0 / 0
19.06.2017, 13:09
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474105
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
И нафига все это нужно?
В реальном бизнес приложении?

самопальные кэши - что бы потом делать самопальные блокировки? и самопальную транзакционность? а что, у СУБД кэши не предусмотрены? Интересна, какая нагрузка на приложение, что такая порнография понадобилась? Может просто научится индексами в БД пользоваться?

минимизировать количество сессий на СУБД (важно, если лицензирование ведется по количеству сессий) - сначала купить дорогую СУБД, а потом ее НЕ использовать? Если она не нужна, зачем тогда ее покупать?

появляются возможности масштабирования горизонтального - честно говоря, где горизонтальное масштабирование, а где вертикальное, я разбираюсь плохо. А просто СУБД с таким же успехом не отмасштабировать? если задача позволяет?

ну и возможности языков типа JAVA и т.п., которые используются на серверах приложений, гораздо шире, чем языки СУБД - ряд СУБД позволяют внутри себя использовать Java. Ну и СУБД надо использовать для обработки ДАННЫХ. А тут, может язык СУБД и не настолько "широк", но значительно УДОБНЕЕ (сужу по PL/SQL). А на Java, ряд дятлов вполне могут полную hibrnate'изацию и приложения, и БД устроить. После чего, hibernate и наступит. И приложению и серверу СУБД. Вот тут как раз и потребуются и кэши и горизонтальная масштабируемость. Сами себе создаем проблемы, потом сами и решаем.

Готов для бизнес приложения признать единственную реальную необходимость еще одного звена, недо-сервера приложений: сервер отчетов или сервер job'ов . Который будет заниматься исключительно отчетами и/или долго рассчитываемыми job'ами (например массовыми операциями)

IMHO & AFAIK
...
Рейтинг: 0 / 0
19.06.2017, 13:25
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474109
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Дядька с усами и часамиLeonid Kudryavtsevможно больше написать кода ==> выше заработокможет быть ещё какие-то аргументы?
Ну если Вы, знающий свою задачу, никаких достоинств не видите... то наверное главный плюс от переусложнения системы - потребовать за нее больше бабла. И за разработку и за саппорт.

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

Во всех других случаях, наверное, более простое решение и более выгодное.

IMHO & AFAIK
...
Рейтинг: 0 / 0
19.06.2017, 13:29
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474110
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Leonid KudryavtsevИ нафига все это нужно?
Он же написал:
- workaround тормознутости СУБД при большом количестве запросов;
- workaround тормознутости СУБД при большом количестве сессий;
- workaround предела вертикального масштабирования;
- workaround неспособности программиста написать нужную логику на языке СУБД и/или приложения.
...
Рейтинг: 0 / 0
19.06.2017, 13:38
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474117
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Dimitry SibiryakovLeonid KudryavtsevИ нафига все это нужно?
....
- workaround неспособности программиста написать нужную логику на языке СУБД и/или приложения.
мне кажется, можно оставить только одно
все предыдущие - просто следствие данного пункта
...
Рейтинг: 0 / 0
19.06.2017, 13:51
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474225
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
schi
Участник
https://habrahabr.ru/company/infopulse/blog/330708/
...
Рейтинг: 0 / 0
19.06.2017, 16:03
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474228
Melkomyagkii_newbi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Melkomyagkii_newbi
Участник
Leonid KudryavtsevDimitry Sibiryakovпропущено...

....
- workaround неспособности программиста написать нужную логику на языке СУБД и/или приложения.
мне кажется, можно оставить только одно
все предыдущие - просто следствие данного пункта

да почему следствие-то? зачем тратить ресурсы субд на создание и убивание сессий, если можно использовать коннекшн пулы? Конечно если полтора пользователя, то пофиг, но если предпологается какая-то нагрузка, то..
...
Рейтинг: 0 / 0
19.06.2017, 16:07
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474403
alexk123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexk123
Участник
Leonid KudryavtsevИ нафига все это нужно?
В реальном бизнес приложении?
сначала купить дорогую СУБД, а потом ее НЕ использовать? Если она не нужна, зачем тогда ее покупать?

IMHO & AFAIK

а зачем покупать эту самую дорогую СУБД? Только для того чтобы пользоваться ее языками типа PL SQL и т.п.? Сервера приложений как раз и позволяют не использовать дорогие СУБД а по возможности и не привязываться к ним. Кому то то достаточно и постгресс, а кому то и Oracle потребуется. Но если завяжитесь на бизнес логику внутри СУБД, то навечно и клиента "прикуете к ней", то сами уже не спрыгните. Есть бюджет клиента - и если окажется что покупка СУБД и лицензий на нее равна 99% бюджета, то это уже не ваш клиент :)

А так - можно скоплектовать систему из одного или нескольких бесплатного сервера приложений и одной или нескольких бесплатных СУБД. И все это будет работать на технике не самого высокого класса. Вы цену владения такой системы для клиента рассматривайте, а не то что вам лично внутри СУБД удобно бизнес-логику писать.
...
Рейтинг: 0 / 0
19.06.2017, 19:07
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474409
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
alexk123...Но если завяжитесь на бизнес логику внутри СУБД, то навечно и клиента "прикуете к ней", то сами уже не спрыгните....

А так - можно скоплектовать систему из одного или нескольких бесплатного сервера приложений и одной или нескольких бесплатных СУБД. И все это будет работать на технике не самого высокого класса. Вы цену владения такой системы для клиента рассматривайте, а не то что вам лично внутри СУБД удобно бизнес-логику писать.[/quot]
...
Рейтинг: 0 / 0
19.06.2017, 19:15
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474413
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Сорри (((
alexk123...Но если завяжитесь на бизнес логику внутри СУБД, то навечно и клиента "прикуете к ней", то сами уже не спрыгните....

А так завяжитесь на сервер приложений и клиента "прикуете к нему"
alexk123...А так - можно скоплектовать систему из одного или нескольких бесплатного сервера приложений и одной или нескольких бесплатных СУБД....
не очень понятно, чем Вам просто бесплатные СУБД не угодили
...
Рейтинг: 0 / 0
19.06.2017, 19:19
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474423
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
Leonid KudryavtsevСорри (((
alexk123...Но если завяжитесь на бизнес логику внутри СУБД, то навечно и клиента "прикуете к ней", то сами уже не спрыгните....

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

Leonid Kudryavtsevalexk123...А так - можно скоплектовать систему из одного или нескольких бесплатного сервера приложений и одной или нескольких бесплатных СУБД....
не очень понятно, чем Вам просто бесплатные СУБД не угодилиБесплатные СУБД очень не нравятся менеджерам высокого звена. С точки зрения менеджера, лучше заплатить за лицензию и иметь возможность в случае чего потребовать от производителя помощь и/или подать на него в суд.
А за бесплатный софт (не только СУБД) не надо платить, но при этом, и за косяки в нем никого нельзя наказать.
И чем серьезнее контора, тем больше проявляется нелюбовь к бесплатному софту.
...
Рейтинг: 0 / 0
19.06.2017, 19:55
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474428
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
White OwlС точки зрения менеджера, лучше заплатить за лицензию и иметь ....
Откат. Увы, но так оно и есть.
...
Рейтинг: 0 / 0
19.06.2017, 20:13
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474430
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Просто, если по каким-то причинам решили купить "серьезную" СУБД, IMHO очень глупо не пользоваться теме возможностями, которые она предоставляет и за которые заплачены деньги. Покупать и платить за лицензии и техподдержку Oracle и при этом использовать его на уровне только стандартного SQL... можно конечно, но, подозреваю, в этом случае, что Oracle, что MySQL, что Postgre SQL будуд совершенно одинаково. Тогда нафига его вообще покупать? (вопрос функционирование экономики по методу распилинга и откатинга не обсуждаем)

С таким же успехом, ради переносимости, можно вообще СУБД не использовать... текстовые файлы - наше все.

Кроме того, не очень понятно, как кэши, переноимости, СУБД независимость и прочее, связаны с сервером приложений.

Нужны Вам дополнительные кэши, при чем тут сервер приложений? С таким же успехом (и даже эффективнее) можно и на клиенте данные кэшировать.

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

Главный недостаток трехзвенки, такой же, как и у двух-звенки. Увеличивается сложность системы, увеличивается кол-во технологий. Нужен больше штат.

На старом, добром FoxPro - нужен один человек. Знающий FoxPro

Двух звенка, нужны C# и SQL'шник. Два человека.

Трех звенка: JavaScript, Java, SQL. Три человека

Ну или ищем full stack. Который об индексах знает, что "есть такая вещь и вроде позволяет скорость выполнения запроса увеличить". Или возьмем ORM, насоздаем объекты, а дальше оно все за нас само сделать должно.

IMHO & AFAIK
...
Рейтинг: 0 / 0
19.06.2017, 20:19
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474481
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Leonid Kudryavtsev,

горизонтальное масштабирование - добавим еще 10 серверов из г.и п., и например переведем на них какую то часть клиентов, например поставим в Сибири и туда всех китайцев
вертикальное - купим сервер на замену в 2 раза быстрее и в 10 раз дороже

для задач, которые хорошо параллелятся вариант 1 явно выгоднее

ну или веб - 2-звенкой трудно обойтись. ок веб не обсуждаем по условиям, но это пока не припрется директор с айпадом и не скажет - хочу...

про кэш на клиенте - это пока нет частых изменений - не для любой задачи пойдет

Еще про кэширование - что из стандартных готовых решений есть кроме таймстен?
...
Рейтинг: 0 / 0
19.06.2017, 22:36
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474545
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Leonid KudryavtsevНа старом, добром FoxPro - нужен один человек. Знающий FoxPro
И что это человек напишет?

Вот гуляют люди по торговому центру и заходят купить тур в Грецию.
Девушка выслушивает их пожелания и накидывает в корзину перелёт, трансферы, проживание, экскурсии, гида.
И делает это не по телефону, а через клиента к системе туроператора.
А система туроператора передаёт заказ принимающим партнёрам в Греции тоже уже не по телефону, или электронной почте, а через API к их сервисам.
И в отель бронь приходит не по факсу, и гид, встречающий приезжающих в аэропорту стоит уже не с бумажкой, где у него записана рассадка в автобусе, а с планшетом.

И не треснет ли одно место у человека, знающего FoxPro, всё это автоматизировать, тестировать, внедрять и поддерживать?
...
Рейтинг: 0 / 0
20.06.2017, 07:22
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474558
Дядька с усами и часами
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дядька с усами и часами
Участник
Теперь такой вопрос.
Вот все говорят "логика на сервере приложений".

Но как делать логику на среднем звене - если логика прежде всего упирается в данные, а данные - на стороне СУБД !
Получается, раз данными заправляет СУБД, значит и логикой заправляет она же?

Или имеется ввиду, что получив данные от клиента, сервер приложений (среднее звено) будет запрашивать у СУБД дополнительные данные из таблиц (именно из таблиц, раз логики на БД нет, то и процедур - нет) и сам будет оперировать этими данными?
...
Рейтинг: 0 / 0
20.06.2017, 08:34
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474561
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Дядька с усами и часамиИли имеется ввиду, что получив данные от клиента, сервер приложений (среднее звено) будет запрашивать у СУБД дополнительные данные из таблиц (именно из таблиц, раз логики на БД нет, то и процедур - нет) и сам будет оперировать этими данными?
Из таблиц, из памяти, у файловой системы, у сторонних сервисов.
Либо ничего не запрашивать, а обрабатывать полученные данные и результат обработки сохранять куда-то, либо пересылать куда-то, либо просто отдавать клиенту.
...
Рейтинг: 0 / 0
20.06.2017, 08:44
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474562
Фотография Areostar
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Areostar
Участник
Дядька с усами и часами,


Данных малова то! Скольео и какая структура пользователей ожидается? какой именно функционал?

Если доступ с нескольких компов то полубому сервер нужен
...
Рейтинг: 0 / 0
20.06.2017, 08:45
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474563
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Дядька с усами и часамиПолучается, раз данными заправляет СУБД, значит и логикой заправляет она же?
Бортовой самописец тоже "заправляет" данными о полёте самолёта :)
...
Рейтинг: 0 / 0
20.06.2017, 08:46
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474564
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
AreostarДядька с усами и часами,


Данных малова то! Скольео и какая структура пользователей ожидается? какой именно функционал?

Если доступ с нескольких компов то полубому сервер нужен
+1

Что за приложение, кому оно нужно, какими данными оперирует, в каком виде их надо отображать конечному пользователю?
...
Рейтинг: 0 / 0
20.06.2017, 08:47
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474565
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Про бизнес-задачу спрашивать не буду :)
...
Рейтинг: 0 / 0
20.06.2017, 08:48
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474568
Дядька с усами и часами
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дядька с усами и часами
Участник
А почему надо конкретизировать? Изначально вопрос звучал более абстрактно - "опишите преимущества трёхзвенки".
...
Рейтинг: 0 / 0
20.06.2017, 08:52
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474572
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Дядька с усами и часами, потому как архитектуру принято выбирать под конкретные задачи, требования и ограничения.

Вангую например, что минимум 80% вашего кода можно завернуть в сборки, что никак не зависят от количества звеньев предполагаемой системы.
То есть не должно быть особых проблем сегодня на этой базе построить клиент-серверное приложение, а завтра при необходимости вынести основную логику на сервер приложений.
...
Рейтинг: 0 / 0
20.06.2017, 09:07
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474574
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
80% вашего C# кода..
...
Рейтинг: 0 / 0
20.06.2017, 09:09
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474609
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
schi
Участник
skyANALeonid KudryavtsevНа старом, добром FoxPro - нужен один человек. Знающий FoxPro
И что это человек напишет?

Вот гуляют люди по торговому центру и заходят купить тур в Грецию.
Девушка выслушивает их пожелания и накидывает в корзину перелёт, трансферы, проживание, экскурсии, гида.
И делает это не по телефону, а через клиента к системе туроператора.
А система туроператора передаёт заказ принимающим партнёрам в Греции тоже уже не по телефону, или электронной почте, а через API к их сервисам.
И в отель бронь приходит не по факсу, и гид, встречающий приезжающих в аэропорту стоит уже не с бумажкой, где у него записана рассадка в автобусе, а с планшетом.

И не треснет ли одно место у человека, знающего FoxPro, всё это автоматизировать, тестировать, внедрять и поддерживать?

И драйвера для железа тоже нельзя на FoxPro писать...
...
Рейтинг: 0 / 0
20.06.2017, 10:30
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474616
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
schiИ драйвера для железа тоже нельзя на FoxPro писать...
шутка неумная
...
Рейтинг: 0 / 0
20.06.2017, 10:43
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474640
17-77
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
17-77
Участник
Дядька с усами и часами,

без конкретики ничего нельзя сказать
в любом случае - разбить на логические слои / сборки / dll можно всегда
а оформлять ли под бизнес слой отдельный хостинг в виде сервера приложений - другой вопрос, и он может быть решен по мере необходимости
если у вас подразумевается доступ к бизнес слою со стороны внешний систем, типа API - тогда делать сервер приложений надо
...
Рейтинг: 0 / 0
20.06.2017, 11:29
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474723
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
Leonid KudryavtsevDimitry Sibiryakovпропущено...

....
- workaround неспособности программиста написать нужную логику на языке СУБД и/или приложения.
мне кажется, можно оставить только одно
все предыдущие - просто следствие данного пункта

ты ошибаешься, причем крупно.

современные СУБД крайне параноидальны и натужны в части обеспечения истинного ACID, который реальным приложениям часто (в примерно 95% случаев) не нужен такой вот чистоты.

и играясь с этими буквами (да да, самопальные блокировки и транзакции) иногда можно разогнать бизнес логику в десятки, а то и сотни раз.

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

при этом случаи бывают еще более тяжелые - все эти семафоры и мутексы приводят к сложности log(n), а то и O(n2), и очень круто и гламурно реализованная бизнес-логика на PL/SQL или T-SQL при росте клиентов от 1-2 до 16 конкурентных просто приводит к своего рода DDoS - транзакции, которые в неконкурентном режиме щелкаются за секунды начинают ворочаться за минуты, что просто выбешивает пользователей.
...
Рейтинг: 0 / 0
20.06.2017, 13:23
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474742
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
skyANA... пропущено
Девушка выслушивает их пожелания и накидывает в корзину перелёт, трансферы, проживание, экскурсии, гида.
И делает это не по телефону, а через клиента к системе туроператора.
А система туроператора передаёт заказ принимающим партнёрам в Греции тоже уже не по телефону, или электронной почте, а через API к их сервисам.
И в отель бронь приходит не по факсу, и гид, встречающий приезжающих в аэропорту стоит уже не с бумажкой, где у него записана рассадка в автобусе, а с планшетом.
... пропущено

При планировании визита президента в какую-либо страну, вероятно, все так и происходит.
А вот для того, чтобы данная система работала в реальной жизни, нужна квалифицированная девушка, хорошо владеющая компьютером, продвинутый консьерж в Греции, толковый гид... И если хоть одно из этих звеньев цепи не замкнется, то пользователю придется ночевать на улице (в аэропорту). Бумажка, она надежней. Проводники в поездах РЖД сличают электронные билеты только по бумажке. Да и я электронные билеты всегда распечатываю, потому как были прецеденты.
...
Рейтинг: 0 / 0
20.06.2017, 13:44
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474785
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Pulsar_pskyANA... пропущено
Девушка выслушивает их пожелания и накидывает в корзину перелёт, трансферы, проживание, экскурсии, гида.
И делает это не по телефону, а через клиента к системе туроператора.
А система туроператора передаёт заказ принимающим партнёрам в Греции тоже уже не по телефону, или электронной почте, а через API к их сервисам.
И в отель бронь приходит не по факсу, и гид, встречающий приезжающих в аэропорту стоит уже не с бумажкой, где у него записана рассадка в автобусе, а с планшетом.
... пропущено

При планировании визита президента в какую-либо страну, вероятно, все так и происходит.
А вот для того, чтобы данная система работала в реальной жизни, нужна квалифицированная девушка, хорошо владеющая компьютером, продвинутый консьерж в Греции, толковый гид... И если хоть одно из этих звеньев цепи не замкнется, то пользователю придется ночевать на улице (в аэропорту). Бумажка, она надежней. Проводники в поездах РЖД сличают электронные билеты только по бумажке. Да и я электронные билеты всегда распечатываю, потому как были прецеденты.
То есть Вы когда путёвку покупаете, то девушка звонит по телефону, а потом ждёт, когда на том конце провода дозвонятся до Греции, я верно понял? :)
...
Рейтинг: 0 / 0
20.06.2017, 14:46
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474810
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
skyANA,
Если честно, никогда путевок не покупал. Гостиницы всегда сам бронировал на сайте. Но я ведь не девушка на ресепшене. :)
...
Рейтинг: 0 / 0
20.06.2017, 15:12
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474829
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
Pulsar_pПроводники в поездах РЖД сличают электронные билеты только по бумажке.
да ну
...
Рейтинг: 0 / 0
20.06.2017, 15:27
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474858
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
ИзопропилPulsar_pПроводники в поездах РЖД сличают электронные билеты только по бумажке.
да ну
За всю Россию не скажу, но со мной было только так. Проводник выходит с распечатанной бумажкой и сличает по ней паспорта пассажиров. Один раз (давно уже правда) проводник заявил, что такую бумажечку ему не предоставили (не знаю, может принтер сломался). Я, предвидя подобный бардак, свой электронный билет распечатал, а вот какой-то гражданочке, после некоторых препирательств, за подтверждением пришлось бежать к начальнику станции.
...
Рейтинг: 0 / 0
20.06.2017, 15:46
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474863
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Pulsar_pskyANA,
Если честно, никогда путевок не покупал. Гостиницы всегда сам бронировал на сайте. Но я ведь не девушка на ресепшене. :)
Кстати сайт - это всего-лишь один из каналов.
То есть нашему сферическому человеку, знающему FoxPro, надо ещё и его поддерживать.

Ещё плюс одна атмосфера в булки :)
...
Рейтинг: 0 / 0
20.06.2017, 15:51
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474867
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Pulsar_pИзопропилпропущено...

да ну
За всю Россию не скажу, но со мной было только так. Проводник выходит с распечатанной бумажкой и сличает по ней паспорта пассажиров. Один раз (давно уже правда) проводник заявил, что такую бумажечку ему не предоставили (не знаю, может принтер сломался). Я, предвидя подобный бардак, свой электронный билет распечатал, а вот какой-то гражданочке, после некоторых препирательств, за подтверждением пришлось бежать к начальнику станции.
Россия как отставала от загнивающего Запада в плане автоматизации лет на 7, так и отстаёт.
...
Рейтинг: 0 / 0
20.06.2017, 15:53
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474891
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
skyANAPulsar_pskyANA,
Если честно, никогда путевок не покупал. Гостиницы всегда сам бронировал на сайте. Но я ведь не девушка на ресепшене. :)
Кстати сайт - это всего-лишь один из каналов.
То есть нашему сферическому человеку, знающему FoxPro, надо ещё и его поддерживать.

Ещё плюс одна атмосфера в булки :)
Я знаю FoxPro, но в его защиту не выступаю. Как раз наоборот, сейчас перевожу АИС'ку из FoxPro на C#+MS SQL. Сложнее всего приходится пользователям. Они привыкли, и просят ничего не менять. Пользователи не выпускники технических вузов, а обычные служащие. Рассуждения про новые технологии их не вдохновляют. Ей-богу, как картошка при Екатерине... Вот потому-то (по возможности) в жизни электронные сервисы всегда подстраховываю бумажками. Примерно как работник мясокомбината никогда не будет есть колбасу...

Про FoxPro: "О мертвых или хорошо или ничего..." (с)
...
Рейтинг: 0 / 0
20.06.2017, 16:07
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474905
NGM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NGM
Участник
[quot skyANA]Pulsar_pпропущено...
Россия как отставала от загнивающего Запада в плане автоматизации лет на 7, так и отстаёт.

Ой ли... Может (дабы сбавить градус категоричности) приведете пару примеров отставания лет на 7 в плане автоматизации чего-либо?
...
Рейтинг: 0 / 0
20.06.2017, 16:17
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474926
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
skyANA... пропущено
Россия как отставала от загнивающего Запада в плане автоматизации лет на 7, так и отстаёт.
Ну я бы не стал так уж однозначно...
Лет 5 назад было... Израильскому другану билет из Питера до Петрозаводска через сайт РЖД заказывал. У них с женой наши только загранпаспорта (двойное гражданство), а у детей так и вообще какие-то местные свидетельства о рождении. На иврите. Так без проблем, все легко и быстро оформил. Они прилетели (а там времени из Пулково до вокзала с гулькин этот самый), быстренько на терминале уже готовые билеты распечатали, и в поезд. Сам не ожидал, что никаких проблем не возникнет. :)
...
Рейтинг: 0 / 0
20.06.2017, 16:32
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474936
Vladimir Baskakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir Baskakov
Участник
Дядька с усами и часамиЗдравствуйте, уважаемые программисты!
Прошу поделиться соображениями вот о чём.
Пишу клиентские desktop приложения (C# WinForms) под Виндовс для работы с Базами Данных (речь о веб-приложениях пока не ведём, обсуждаем только desktop).
Код: c#
1.
Клиентское приложение <----> СУБД

Напишите, какие по вашему мнению существуют преимущества у трёхзвенной схемы:
Код: c#
1.
Клиентское приложение <----> Сервер Приложений <----> СУБД

Также буду рад прочесть о случаях из вашей практики в пользу той или иной точки зрения.
Спасибо.

(Проходя мимо).
Вот у SAP - есть и клиент и сервер. То есть, до какого-то уровня сложности решения, третье звено только мешает. И только с ростом и структурированием системы начинает помогать. и не все дорастают до круга задач, где сервер приложений (при наличии своего клиента) реально нужен.
...
Рейтинг: 0 / 0
20.06.2017, 16:37
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474941
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Pulsar_pskyANAпропущено...

Кстати сайт - это всего-лишь один из каналов.
То есть нашему сферическому человеку, знающему FoxPro, надо ещё и его поддерживать.

Ещё плюс одна атмосфера в булки :)
Я знаю FoxPro, но в его защиту не выступаю. Как раз наоборот, сейчас перевожу АИС'ку из FoxPro на C#+MS SQL. Сложнее всего приходится пользователям. Они привыкли, и просят ничего не менять. Пользователи не выпускники технических вузов, а обычные служащие. Рассуждения про новые технологии их не вдохновляют. Ей-богу, как картошка при Екатерине... Вот потому-то (по возможности) в жизни электронные сервисы всегда подстраховываю бумажками. Примерно как работник мясокомбината никогда не будет есть колбасу...

Про FoxPro: "О мертвых или хорошо или ничего..." (с)
Согласен, что интерфейс для пользователя должен быть узнаваем. Но в чём проблема его сделать таким на C#?
...
Рейтинг: 0 / 0
20.06.2017, 16:44
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474942
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
NGMskyANAРоссия как отставала от загнивающего Запада в плане автоматизации лет на 7, так и отстаёт.

Ой ли... Может (дабы сбавить градус категоричности) приведете пару примеров отставания лет на 7 в плане автоматизации чего-либо?
Пожалуйста: санатории Белокурихи .
...
Рейтинг: 0 / 0
20.06.2017, 16:50
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474944
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Сравните с Карловы Вары .
...
Рейтинг: 0 / 0
20.06.2017, 16:51
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474952
NGM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NGM
Участник
skyANAСравните с Карловы Вары .

Сравниваю .
...
Рейтинг: 0 / 0
20.06.2017, 17:02
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474956
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
skyANAPulsar_pпропущено...

Я знаю FoxPro, но в его защиту не выступаю. Как раз наоборот, сейчас перевожу АИС'ку из FoxPro на C#+MS SQL. Сложнее всего приходится пользователям. Они привыкли, и просят ничего не менять. Пользователи не выпускники технических вузов, а обычные служащие. Рассуждения про новые технологии их не вдохновляют. Ей-богу, как картошка при Екатерине... Вот потому-то (по возможности) в жизни электронные сервисы всегда подстраховываю бумажками. Примерно как работник мясокомбината никогда не будет есть колбасу...

Про FoxPro: "О мертвых или хорошо или ничего..." (с)
Согласен, что интерфейс для пользователя должен быть узнаваем. Но в чём проблема его сделать таким на C#?
А в чем была проблема сделать интерфейс Windows 10 таким же, как Windows 7 ?
Везде есть своя специфика. Кроме того (как показывает практика) самое сложное, это переходный процесс. Потом спасибо скажут. (Если не прибьют по пути). :)
...
Рейтинг: 0 / 0
20.06.2017, 17:04
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474961
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Pulsar_pА в чем была проблема сделать интерфейс Windows 10 таким же, как Windows 7 ?
А зачем? Потому как есть какой-то процент людей у кого проблемы с переходным процессом? И каков он? Только не говорите, что большинство Ваших знакомых :)
...
Рейтинг: 0 / 0
20.06.2017, 17:14
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474964
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
skyANANGMпропущено...


Ой ли... Может (дабы сбавить градус категоричности) приведете пару примеров отставания лет на 7 в плане автоматизации чего-либо?
Пожалуйста: санатории Белокурихи .

Прошу прощения, а что Вас конкретно не устроило?
Для окраин России вполне ничего сайт . И даже онлайн бронирование есть.
...
Рейтинг: 0 / 0
20.06.2017, 17:18
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474970
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
skyANA... пропущено
Согласен, что интерфейс для пользователя должен быть узнаваем. Но в чём проблема его сделать таким на C#?
skyANA... пропущено
А зачем? Потому как есть какой-то процент людей у кого проблемы с переходным процессом?
Вы сами прекрасно ответили на свой собственный вопрос. :)
...
Рейтинг: 0 / 0
20.06.2017, 17:24
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474973
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Pulsar_pskyANAпропущено...

Пожалуйста: санатории Белокурихи .

Прошу прощения, а что Вас конкретно не устроило?
Для окраин России вполне ничего сайт . И даже онлайн бронирование есть.
Кнопку пробовали нажимать, есть то она есть, да не везде работает: тынц :)

Ну и "Мы получим вашу заявку и свяжемся в ближайшее рабочее время" - это ни фига не онлайн бронирование :)
...
Рейтинг: 0 / 0
20.06.2017, 17:28
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474976
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Pulsar_pskyANA... пропущено
Согласен, что интерфейс для пользователя должен быть узнаваем. Но в чём проблема его сделать таким на C#?
skyANA... пропущено
А зачем? Потому как есть какой-то процент людей у кого проблемы с переходным процессом?
Вы сами прекрасно ответили на свой собственный вопрос. :)
Да, у меня есть мнение на этот счёт.
...
Рейтинг: 0 / 0
20.06.2017, 17:29
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474986
Pulsar_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pulsar_p
Участник
skyANA
... пропущено
Ну и "Мы получим вашу заявку и свяжемся в ближайшее рабочее время" - это ни фига не онлайн бронирование :)
Зато в Белокуриху можно бесплатно позвонить и Вам все объяснят. Карловы Вары такого сервиса не предоставляют. :)
...
Рейтинг: 0 / 0
20.06.2017, 17:44
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39474991
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Leonid Kudryavtsev минимизировать количество сессий на СУБД (важно, если лицензирование ведется по количеству сессий) - сначала купить дорогую СУБД, а потом ее НЕ использовать?В моей практике был случай, когда из-за "row lock contention" дорогой СУБД требовалось более дорогое железо, чем было на тот момент. Хотя несложная агрегация примитивного запроса на сервере приложений - решила бы проблему. Тем более, что сервер приложений уже был.
...
Рейтинг: 0 / 0
20.06.2017, 17:49
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475005
NGM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
NGM
Участник
skyANA,

Просто уточняю - "101Отелей" претензии по существу поднятой темы имеются? Просто я им пользуюсь чаще, чем Букингом (в поездках по России, разумеется), может чего не знаю о прорывах в автоматизации онлайн-бронирования.
...
Рейтинг: 0 / 0
20.06.2017, 18:10
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475042
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Basil A. Sidorov...несложная агрегация примитивного запроса на сервере приложений - решила бы проблему.....
а что есть "агрегация" в этом контексте?
если group by, то как-то не верится, что его дешевле сделать на сервере приложений

ну и уж тем более не верится, что ту же логику нельзя было бы сделать в stored procedure, без всякого обмена данными между БД и App серверами
...
Рейтинг: 0 / 0
20.06.2017, 19:34
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475065
kealon(Ruslan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kealon(Ruslan)
Участник
Leonid Kudryavtsev,

я бы посмотрел как вы на уровне БД будете решать, например, "задача о рюкзаке" или "задача коммивояжера"
...
Рейтинг: 0 / 0
20.06.2017, 20:26
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475077
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
kealon(Ruslan)я бы посмотрел как вы на уровне БД будете решать, например, "задача о рюкзаке" или "задача коммивояжера"
Лично я - легко. Если потребуется делать это именно на стороне сервера, а не достаточно сделать просто на клиенте.

Ну и например, если мы говорим не о сферической БД, то, вроде (сам с этим не работал), например Oracle декларирует, что поддерживает графы. Т.ч., подозреваю, "задача коммивояжера" должна там решаться одной или несколькими строчками ))) Насколько эффективно, другой вопрос. Не верю я как-то в новомодные картриджи от Oracle Co. )))
...
Рейтинг: 0 / 0
20.06.2017, 20:43
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475078
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dima T
Участник
Basil A. SidorovLeonid Kudryavtsev минимизировать количество сессий на СУБД (важно, если лицензирование ведется по количеству сессий) - сначала купить дорогую СУБД, а потом ее НЕ использовать?В моей практике был случай, когда из-за "row lock contention" дорогой СУБД требовалось более дорогое железо, чем было на тот момент. Хотя несложная агрегация примитивного запроса на сервере приложений - решила бы проблему. Тем более, что сервер приложений уже был.
Есть хинт NOLOCK (в MSSQL, наверно и в оракле что-то похожее есть), который решает проблему блокировок когда не надо атомарную точность, но готовы ли его использовать разработчики? Проще посоветовать железа докупить, чем на себя взять такую ответственность.
...
Рейтинг: 0 / 0
20.06.2017, 20:43
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475151
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
alexk123-
- минимизировать количество сессий на СУБД (важно, если лицензирование ведется по количеству сессий), требования к серверу СУБД становятся меньшими (как за счет меньшего количества сессий, так и переноса логики)



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

alexk123- ну и возможности языков типа JAVA и т.п., которые используются на серверах приложений, гораздо шире, чем языки СУБД

сомнительное преимущество, во многих субд есть возможность писать не только на sql, и возможности Java как правило ограничены, не тот это язык, чтобы на нем было удобно БЛ писать.
...
Рейтинг: 0 / 0
21.06.2017, 04:36
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475152
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
появляются возможности масштабирования горизонтального - честно говоря, где горизонтальное масштабирование, а где вертикальное, я разбираюсь плохо. А просто СУБД с таким же успехом не отмасштабировать? если задача позволяет?

звено субд хорошо масштабируется на несколько тысяч соединений, несколько десятков тысяч соединений, а дальше нет.
...
Рейтинг: 0 / 0
21.06.2017, 04:40
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475154
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
ты ошибаешься, причем крупно.

современные СУБД крайне параноидальны и натужны в части обеспечения истинного ACID, который реальным приложениям часто (в примерно 95% случаев) не нужен такой вот чистоты.


смотря какие приложения. Если очередной говносайт, то да, в 100% не нужно ACID, но там и сам сайт заведомо никому не нужен.

тем не менее, ты сейчас сидишь на сайте, который работает полностью на 100% ACID СУБД SqlServer...
...
Рейтинг: 0 / 0
21.06.2017, 04:50
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475287
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
NGMskyANA,

Просто уточняю - "101Отелей" претензии по существу поднятой темы имеются? Просто я им пользуюсь чаще, чем Букингом (в поездках по России, разумеется), может чего не знаю о прорывах в автоматизации онлайн-бронирования.
Не пользовался, интегрироваться не пробовал. API есть? Мобильное приложение есть?
...
Рейтинг: 0 / 0
21.06.2017, 11:05
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475326
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
MasterZiv... сомнительное преимущество, во многих субд есть возможность писать не только на sql, и возможности Java как правило ограничены, не тот это язык, чтобы на нем было удобно БЛ писать .На C# LINQ писать БЛ удобно. Даже удобнее...
...
Рейтинг: 0 / 0
21.06.2017, 11:32
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475586
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
MasterZivmeты ошибаешься, причем крупно.

современные СУБД крайне параноидальны и натужны в части обеспечения истинного ACID, который реальным приложениям часто (в примерно 95% случаев) не нужен такой вот чистоты.



смотря какие приложения. Если очередной говносайт, то да, в 100% не нужно ACID, но там и сам сайт заведомо никому не нужен.
говносайт? ну ок, фейсбуки и всякие там вконтактики и ютубики запишем в говносайтики тоже? ок, ну и ладно, они деньги не считают.

возьмем класс задач вроде Биржа, нефтяные котировки, форексы, да те-же биткоины, достаточно убедительно?
ты всерьез считаешь, что там, на биржах каждая сделка приводит к абсолютно безусловной pure-true-ACID транзакции в базу данных со всеми row-lock contention и log-sync-IO-wait на диск?

серьезно?

ты видел хоть раз нагрузку чуть более мощную, чем 1С бухгалтерия или веб сайт с продажей в 100 сделок в день максимум?

MasterZivтем не менее, ты сейчас сидишь на сайте, который работает полностью на 100% ACID СУБД SqlServer...
скуль это сайт ниже средней, скорее малой нагрузки. тут по определению нет сотен тысяч фактов/запросов/транзакций в секунду.
...
Рейтинг: 0 / 0
21.06.2017, 15:48
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39475590
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
MasterZiv появляются возможности масштабирования горизонтального - честно говоря, где горизонтальное масштабирование, а где вертикальное, я разбираюсь плохо. А просто СУБД с таким же успехом не отмасштабировать? если задача позволяет?

звено субд хорошо масштабируется на несколько тысяч соединений, несколько десятков тысяч соединений, а дальше нет.
зачем СУБД несколько десятков, да даже тысяч соединений? вы там что, онлайн-чат делаете?

для таких вещей есть libevent и прочие erlang, goroutines

а так - ты попробуй на базе данных исполнить хотя-бы пару десятков активных конкурирующих транзакций, и замерь "срупут ин авэридж диградейшн"
...
Рейтинг: 0 / 0
21.06.2017, 15:52
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39476445
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Leonid Kudryavtsevа что есть "агрегация" в этом контексте?Много клиентов, действия которых пишутся в разные таблицы.
Одна из таких таблиц использовалась для отслеживания активности клиентов путём регулярного обновления счётчика действий в маленькой записи, которая создавалась вместе с клиентской сессией.
Несколько сотен (коротких) транзакций (по одному запросу на значимое действие каждого клиента), эффект девятого вала и классическая спираль смерти при катастрофическом росте LA.ну и уж тем более не верится, что ту же логику нельзя было бы сделать в stored procedure, без всякого обмена данными между БД и App серверамиХранимые процедуры научились получать внешние данные через флюиды космоса?
...
Рейтинг: 0 / 0
22.06.2017, 21:36
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477212
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Basil A. Sidorov,
хранимки могут использовать UDF, написанные, в том числе и на java, соответственно получать и внешние данные из космоса...
...
Рейтинг: 0 / 0
25.06.2017, 06:54
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477213
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
если убрать серверное приложнние — то это засветка порта субд в инет, что само по себе уже плохо.
протокол обмена это sql строка - что свидетельствует об обязательном шифровании трафика.
если убрать серверное приложение - то это лишняя нагрузка на сервер, потому как каждому клиенту надо достучаться на сервер, спрашивая если для него инфа. серверное приложение само может рассылать данные клиентам. при этом даже не обращаясь к субд. соответственно более мягкие требования к железу при этом более высокое быстродействие всей системы.
при наличии серверного приложения , клиентом может быть и браузер и десктоп. одновременно.
...
Рейтинг: 0 / 0
25.06.2017, 07:22
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477248
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
Коллеги,

а как бы Вы отнеслись к возможности писать ИС (исключая интерфейс) на голом SQL, в который интегрированы полноценные ОО возможности? (Ну.. назовем его , скажем, SQL++ :-) )
Не криво, как в ОРСУБД, а прям нормально, так что удобно, просто и везде применимо?

Были бы для Вас какие-то плюсы от этого.
Возможность такового предлагаю пока оставить за скобками, просто гипотетический вариант.
А?
...
Рейтинг: 0 / 0
25.06.2017, 13:59
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477251
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Мурыч,

отрицательно
опыт индустрии показал, что это не живет
...
Рейтинг: 0 / 0
25.06.2017, 14:18
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477252
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglМурыч,

отрицательно
опыт индустрии показал, что это не живет

Ну да, был такой опыт. Но давайте представим что это живет, тогда?
...
Рейтинг: 0 / 0
25.06.2017, 14:24
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477276
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Мурыча как бы Вы отнеслись к возможности писать ИС (исключая интерфейс) на голом SQL
Тогда это уже не будет SQL, а будет FUIL. По определению!

SQL = Structural Query Language
FUIL = Fa...ing User Interface Language

На SQL писать интерфейсы, как на английском языке русским матом разговаривать, от всего богатства языка, только shit и double shit останется ((( Пользователи не поймут.

А вот на FUIL, писать пользовательские интерфейсы будет очень удобно. Хоть в название языка и 4 буквы, но пользователи сразу после установки программы на компьютер будут понимать, что послали их на 3. И лишних вопросов к службе поддержки у них не возникнет.

IMHO
...
Рейтинг: 0 / 0
25.06.2017, 17:02
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477302
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
Leonid KudryavtsevМурыча как бы Вы отнеслись к возможности писать ИС (исключая интерфейс) на голом SQL
Тогда это уже не будет SQL, а будет FUIL. По определению!

SQL = Structural Query Language
FUIL = Fa...ing User Interface Language

На SQL писать интерфейсы, как на английском языке русским матом разговаривать, от всего богатства языка, только shit и double shit останется ((( Пользователи не поймут.

А вот на FUIL, писать пользовательские интерфейсы будет очень удобно. Хоть в название языка и 4 буквы, но пользователи сразу после установки программы на компьютер будут понимать, что послали их на 3. И лишних вопросов к службе поддержки у них не возникнет.

IMHO

Да, все что касается интерфейса - святая правда. Но я спрашивал про все кроме интерфейса.

А вообще, остроумие - не всегда признак ума, а зачастую и наоборот. Возможно это и не про вас, но всеж поаккуратнее бы вам со своим имхо. Как говорится - береги имхо смолоду.
...
Рейтинг: 0 / 0
25.06.2017, 18:47
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477315
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Мурыч,ты зря его так..
он действительно верно обозначил эту ситуацию. твой вариант возможен, но только как демонстрация хитроумности ума...
чисто на хранимках можно вывести практически всё
...
Рейтинг: 0 / 0
25.06.2017, 20:02
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477320
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
вадяМурыч,ты зря его так..
он действительно верно обозначил эту ситуацию. твой вариант возможен, но только как демонстрация хитроумности ума...
чисто на хранимках можно вывести практически всё

Я человек мира, не шалю, никого не трогаю, починяю примус)

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

Вот хранимки - удобно? Удобно. Если классы будут в sql нормально жить, тоже ведь будет удобно?
Тогда в принципе от аппликейшн сервера можно будет отказаться.
Как вам такая перспектива?
...
Рейтинг: 0 / 0
25.06.2017, 20:20
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477324
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
МурычКак вам такая перспектива?
бесперспективно.
говнокод от данных желательно отделять.
данные обычно ценнее и могут быть обработаны разными инструментами
...
Рейтинг: 0 / 0
25.06.2017, 20:33
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477328
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
ИзопропилМурычКак вам такая перспектива?
бесперспективно.
говнокод от данных желательно отделять.
данные обычно ценнее и могут быть обработаны разными инструментами

Главное отделять говно от код.
Правильно я понял что если будет обеспечена сохранность данных, то перспективно?
...
Рейтинг: 0 / 0
25.06.2017, 20:56
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477329
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Мурыч,

ООП попендикулярно сиквелу. Разные парадигмы т.е

А продвинутую логику в базе - пожалуйста pl/sql, pl/pgsql, на худой конец psql, а хочется объектных извращений - кашаскрипт
...
Рейтинг: 0 / 0
25.06.2017, 20:56
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477332
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
Изопропилговнокод от данных желательно отделять.


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

В конце концов, я могу сказать что "говноцифирьки" тоже есть бгггг. На самом деле, штука в том, что инструменты хранения данных были ориентированы в первую очередь на цифирьки, но не на алгоритмы.
...
Рейтинг: 0 / 0
25.06.2017, 21:15
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477333
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglМурыч,

ООП попендикулярно сиквелу. Разные парадигмы т.е

А продвинутую логику в базе - пожалуйста pl/sql, pl/pgsql, на худой конец psql, а хочется объектных извращений - кашаскрипт

Да знаю я про этот импеданс мисматч, но не вечен же он. Раньше думали что земля плоская. И хочется объектных, но не извращений.

Да в общем не о том речь. Импеданс, не импеданс, не имеет значения. Я собственно спросил о том что если в sql появятся ооп возможности, сравнимые с с++, или даже более мощные, и будет возможность для хранения и обработки данных использовать только реляционную субд, и отказаться от аппликейшн сервера, будет ли это кому-то интересно?

Я не обсуждаю возможно это или нет, потому что это отдельный и не маленький разговор, учитывая понятный мне негативный опыт индустрии.
...
Рейтинг: 0 / 0
25.06.2017, 21:16
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477335
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
Мурычбудет ли это кому-то интересно?
кому-то - может быть

но критическая масса интересующихся не набралась
...
Рейтинг: 0 / 0
25.06.2017, 21:21
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477338
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
SiemarglООП попендикулярно сиквелу. Разные парадигмы т.е
Именно что перпенжикулярны, ничто не мешает их свести вместе.
http://www.odbms.org/2012/08/impedance-mismatch-is-not-an-objects-vs-relations-problem-draft/
...
Рейтинг: 0 / 0
25.06.2017, 21:22
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477341
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Мурыч,

Дык ООП в чистом виде устарело. И скрещивается с алгеброй сиквела не очень производительно.

Если будет хороший фреймворк для x-sql, то можно его успешно применять и без полноценного ооп-подхода.
Например объекты(модули) но без наследования и/или без виртуализации.

Только это опять будет тяготеть к 2-звенке со всеми ее достоинствами и --ми.

Итого - получится АПЕКС =)
...
Рейтинг: 0 / 0
25.06.2017, 21:47
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477351
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
ИзопропилМурычбудет ли это кому-то интересно?
кому-то - может быть

но критическая масса интересующихся не набралась

Ну так это нормально, 90% народа живет по принципу ничего не вижу, ничего не слышу. И это, кстати, тоже нормально.
...
Рейтинг: 0 / 0
25.06.2017, 22:18
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477352
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglМурыч,

Дык ООП в чистом виде устарело. И скрещивается с алгеброй сиквела не очень производительно.

Если будет хороший фреймворк для x-sql, то можно его успешно применять и без полноценного ооп-подхода.
Например объекты(модули) но без наследования и/или без виртуализации.

Только это опять будет тяготеть к 2-звенке со всеми ее достоинствами и --ми.

Итого - получится АПЕКС =)

Так то в чистом, а то скрещенное с реляционной моделью, это другая история.
Ну так что важнее для вас, то что есть известные вам решения, или потенциальная низкая производительность?
...
Рейтинг: 0 / 0
25.06.2017, 22:26
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477353
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
МурычИзопропилпропущено...

кому-то - может быть

но критическая масса интересующихся не набралась

Ну так это нормально, 90% народа живет по принципу ничего не вижу, ничего не слышу. И это, кстати, тоже нормально.

Это даже хорошо - меньше конкурентов.
...
Рейтинг: 0 / 0
25.06.2017, 22:27
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477356
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
МурычSiemarglМурыч,

Дык ООП в чистом виде устарело. И скрещивается с алгеброй сиквела не очень производительно.

Если будет хороший фреймворк для x-sql, то можно его успешно применять и без полноценного ооп-подхода.
Например объекты(модули) но без наследования и/или без виртуализации.

Только это опять будет тяготеть к 2-звенке со всеми ее достоинствами и --ми.

Итого - получится АПЕКС =)

Так то в чистом, а то скрещенное с реляционной моделью, это другая история.
Ну так что важнее для вас, то что есть известные вам решения, или потенциальная низкая производительность?
Я использую родные для платформ решения. т.е в данном контексте голый sql.

В ущерб своему удобству первичного написания.

Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится. (с) Поэтому
...
Рейтинг: 0 / 0
25.06.2017, 22:37
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477357
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglМурычпропущено...


Так то в чистом, а то скрещенное с реляционной моделью, это другая история.
Ну так что важнее для вас, то что есть известные вам решения, или потенциальная низкая производительность?
Я использую родные для платформ решения. т.е в данном контексте голый sql.

В ущерб своему удобству первичного написания.

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


УУУх ))) Очень образно Вы выражаетесь)))
Вы хотите сказать что используете то что знаете, даже понимая что все это может привести к последующим переработкам и переделкам?
...
Рейтинг: 0 / 0
25.06.2017, 22:48
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477358
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Мурыч,

Наоборот, под каждую новую для меня инфраструктуру, я смотрю типовые для _этой структуры_ подходы.

А пишу я под много чего...
...
Рейтинг: 0 / 0
25.06.2017, 22:49
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477363
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglМурыч,

Наоборот, под каждую новую для меня инфраструктуру, я смотрю типовые для _этой структуры_ подходы.

А пишу я под много чего...

Хотите сказать что главное чтобы то чем Вы пользуетесь было типовым решением?

Для Вас даже менее важны затраты, производительность и гибкость решения?
...
Рейтинг: 0 / 0
25.06.2017, 23:14
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477367
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Мурыч,
можно в хранимке/запросе сформировать данные так, чтоб только вставить в таблицу в браузере, дату в нужном формате, числа красиво сформатировать, даже html тэги добавить....и вывести это одной строкой чтоб передать её в браузер, и вставить командой innerHTML.
но это извращение.
...
Рейтинг: 0 / 0
25.06.2017, 23:28
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477368
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
МурычSiemarglМурыч,

Наоборот, под каждую новую для меня инфраструктуру, я смотрю типовые для _этой структуры_ подходы.

А пишу я под много чего...

Хотите сказать что главное чтобы то чем Вы пользуетесь было типовым решением?

Для Вас даже менее важны затраты, производительность и гибкость решения?
Производительность типовых рекомендованных решений "от производителя" высокая.

Затраты/гибкость меня волнуют меньше.

Предлагаю вместо обсуждений реальных решений Вам вернуться к обсуждению нереалистичного SQL+++
...
Рейтинг: 0 / 0
25.06.2017, 23:31
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477370
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
МурычВот хранимки - удобно? Удобно.
Хранимки на SQL написать не возможно в ПРИНЦИПЕ !
Хранимки пишут на каком нибудь языке программирования, а не на SQL.

МурычЕсли классы будут в sql нормально жить, тоже ведь будет удобно?

Они и так нормально живут. Так же, как нормально живут тексты, видео и любая другая информация закодированная в виде последовательности битиков и байтиков.

SELECT mySeriallizedClass FROM myTable WHERE id=:p_id;

SiemarglООП попендикулярно сиквелу. Разные парадигмы т.е

А продвинутую логику в базе - пожалуйста pl/sql, pl/pgsql, на худой конец psql, а хочется объектных извращений - кашаскрипт
+100500

и я о том же....

При чем тут вообще ООП, я полностью не понял.

ВикипедияСервер приложений (англ. application server) — это программная платформа (фреймворк), предназначенная для эффективного исполнения процедур (программ, скриптов), на которых построены приложения....

Любая современная СУБД УЖЕ является сервером приложений.
При чем тут ООП, SQL... и прочий винегрет, совершенно не понятно.
...
Рейтинг: 0 / 0
25.06.2017, 23:36
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477373
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Leonid Kudryavtsev,

Пассаж про хранимки без контекста не понял.
...
Рейтинг: 0 / 0
25.06.2017, 23:46
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477375
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Leonid Kudryavtsev,
ты про написание хранимок серьёзно?
...
Рейтинг: 0 / 0
25.06.2017, 23:56
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477390
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
вадяLeonid Kudryavtsev,
ты про написание хранимок серьёзно?
что про хранимки?
что "их на SQL не пишут" ?

конечно серьезно

В Oracle их пишут на PL/SQL или Java
В MS SQL их пишут на Transact SQL
В Postgress на PL/pgSQL

AFAIK. Может конечно отстал от жизни. И сейчас все изменилось.
...
Рейтинг: 0 / 0
26.06.2017, 00:28
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477394
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglМурычпропущено...


Хотите сказать что главное чтобы то чем Вы пользуетесь было типовым решением?

Для Вас даже менее важны затраты, производительность и гибкость решения?
Производительность типовых рекомендованных решений "от производителя" высокая.

Затраты/гибкость меня волнуют меньше.

Предлагаю вместо обсуждений реальных решений Вам вернуться к обсуждению нереалистичного SQL+++

Почему нереалистичного? Август - сентябрь - в Firebird 3.
...
Рейтинг: 0 / 0
26.06.2017, 00:32
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477395
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Leonid KudryavtsevвадяLeonid Kudryavtsev,
ты про написание хранимок серьёзно?
что про хранимки?
что "их на SQL не пишут" ?

конечно серьезно

В Oracle их пишут на PL/SQL или Java
В MS SQL их пишут на Transact SQL
В Postgress на PL/pgSQL

AFAIK. Может конечно отстал от жизни. И сейчас все изменилось.
Ну настолько акцентироваться на отличиях sql ansi от реализаций - это буквоедство, надо за такое морду бить )
МурычSiemarglпропущено...

Производительность типовых рекомендованных решений "от производителя" высокая.

Затраты/гибкость меня волнуют меньше.

Предлагаю вместо обсуждений реальных решений Вам вернуться к обсуждению нереалистичного SQL+++

Почему нереалистичного? Август - сентябрь - в Firebird 3.
Я упоминал psql. FB3 уже давно вышла, 3.0.2 на дворе
...
Рейтинг: 0 / 0
26.06.2017, 00:46
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477398
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglПочему нереалистичного? Август - сентябрь - в Firebird 3.
Я упоминал psql. FB3 уже давно вышла, 3.0.2 на дворе[/quot]

Да, но в FB3 пока обычный сиквел, пусть и с процедурной частью. Будет с классами. Можно будет средствами сиквела создавать классы, методы, объекты, и манипулировать ими. Все старые возможности сохраняются.
...
Рейтинг: 0 / 0
26.06.2017, 00:55
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477399
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Мурыч,

Я еще упоминал ее "на крайний случай" - там интересные особенности. Сервер за целостностью [метаданных] следит как мама несовершеннолетней дочки. Ты на ходу ничего поменять в структуре толком не можешь, причем транзакции мимо. Отладка в ООП-технике будет адом.

Подробности лучше уточни в профильной ветке, я так себе в курсе - только примус починяю.
...
Рейтинг: 0 / 0
26.06.2017, 01:00
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477401
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglМурыч,

Я еще упоминал ее "на крайний случай" - там интересные особенности. Сервер за целостностью [метаданных] следит как мама несовершеннолетней дочки. Ты на ходу ничего поменять в структуре толком не можешь, причем транзакции мимо. Отладка в ООП-технике будет адом.

Подробности лучше уточни в профильной ветке, я так себе в курсе - только примус починяю.

Спасибо за предупреждение. У Вас видимо какие-то свои представления о том как это сделано, но реальность немного другая. Этих рисков там нет. Отладка будет - одно удовольствие.))
...
Рейтинг: 0 / 0
26.06.2017, 01:15
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477402
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
SiemarglНу настолько акцентироваться на отличиях sql ansi от реализаций - это буквоедство, надо за такое морду бить )


НЕТ !!! [цензурой русский язык вырезан]
Это НЕ реализация. SQL - это [цензурой вырезано] Query Language.

PL/SQL - это сокращение от Procedural Language

HTML - это сокращение от Hipertext Markup Language

а CSS - это даже не language, а Cascading Style Sheets )))

Давайте тогда уж сразу на HTML сторед процедуры писать. А мелочи реализации - это буквоедство.

Все эти споры, очень сильно напоминают Айсидору Дункан. Если все делать через одно место, то и появляется желание скрестить ООП и SQL. Если все делать нормально, то и желаний таких не возникает. Дабы одно теплое, а другое мягкое. А если их скрещивать, то может получится что то еще и дурно пахнущее.

 

- Извиняюсь, - перебил его Швондер, - вот именно по поводу столовой и смотровой мы и пришли говорить. Общее собрание просит вас добровольно, в порядке трудовой дисциплины, отказаться от столовой. Столовых ни у кого нет в Москве.

- Даже у Айседоры Дункан! - звонко крикнула женщина.

С Филиппом Филипповичем что-то сделалось, вследствие чего его лицо нежно побагровело, но он не произнес ни одного звука, выжидая что будет дальше.

- И от смотровой также, - продолжал Швондер, - смотровую прекрасно можно соединить с кабинетом.

- Угу, - молвил Филипп Филиппович каким-то странным голосом, - а где же я должен принимать пищу?

- В спальне, - хором ответили четверо.

Багровость Филипп Филипповича приняла несколько сероватый оттенок.

- В спальне принимать пищу, - заговорил он придушенным голосом, - в смотровой - читать, в приемной - одеваться, оперировать - в комнате прислуги, а в столовой - осматривать? Очень возможно, что Айседора Дункан так и делает. Может быть, она в кабинете обедает, а кроликов режет в ванной. Может быть... Но я не Айседора Дункан!! - вдруг рявкнул он, и багровость его стала желтой. - Я буду обедать в столовой, а оперировать в операционной! Передайте это общему собранию, и покорнейше прошу вас вернуться к вашим делам, а мне предоставить возможность принять пищу там, где ее принимают все нормальные люди, то есть в столовой, а не в передней и не в детской.



p.s. Пошутил про сторед процедуры на HTML... Но ведь уже и до этого дошло. Народ уже начинает пропагандировать подход, когда вся логика на JavaScript'е, а через AJAX и REST чисто SELECT'ы гоняются....
...
Рейтинг: 0 / 0
26.06.2017, 01:32
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477412
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Leonid Kudryavtsev,
тебе просто хочется пов...ся, в любом случае необходимо указывать имя субд mssql, mysql, fb,....
и этим будет сказаны все языковые тонкости и различия sql.
...
Рейтинг: 0 / 0
26.06.2017, 06:35
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477422
Дядька с усами и часами
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дядька с усами и часами
Участник
Господа, господа!
(звон председательского колокольчика)
Попрошу не отклоняться от темы!
...
Рейтинг: 0 / 0
26.06.2017, 08:16
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477448
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
вадятебе просто хочется пов...ся, в любом случае необходимо указывать имя субд mssql, mysql, fb,....
и этим будет сказаны все языковые тонкости и различия sql.

Да нет языковых тонкостей

SQL (Select) для программирования (написания кода) не предназначен. И Select изначально предназначен исключительно как язык доступа к нормализованным реляционным данным, представленный в виде нормализованных табличек и описания отношений между ними.

Для программирования сторед процедур предназначены языки ПРОГРАММИРОВАНИЯ.

В последних, проблем с ООП нет как класс. Ну хочешь ООП, ну создай себе классы хотья на Java, хоть на PL/SQL. В чем-пробема?

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

Специально нашел Гради Буча "Объектно ориентированный анализ и проектирование". На 3-ей же страницы

 

Пять признаков сложной системы

Исходя из такого способа изучения, можно вывести пять общих признаков любой сложной системы. Основываясь на работе Саймона и Эндо, Куртуа предлагает следующее наблюдение [7]:

1. "Сложные системы часто являются иерархическими и состоят из взаимозависимых подсистем, которые в свою очередь также могут быть разделены на подсистемы, и т.д., вплоть до самого низкого уровням."

Саймон отмечает: "тот факт, что многие сложные системы имеют почти разложимую иерархическую структуру, является главным фактором, позволяющим нам понять, описать и даже "увидеть" такие системы и их части" [8]. В самом деле, скорее всего, мы можем понять лишь те системы, которые имеют иерархическую структуру.

Важно осознать, что архитектура сложных систем складывается и из компонентов, и из иерархических отношений этих компонентов. Речтин отмечает: "Все системы имеют подсистемы, и все системы являются частями более крупных систем... Особенности системы обусловлены отношениями между ее частями, а не частями как таковыми" [9].

Что же следует считать простейшими элементами системы? Опыт подсказывает нам следующий ответ:

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

Низший уровень для одного наблюдателя может оказаться достаточно высоким для другого.

Саймон называет иерархические системы разложимыми, если они могут быть разделены на четко идентифицируемые части, и почти разложимыми, если их составляющие не являются абсолютно независимыми. Это подводит нас к следующему общему свойству всех сложных систем:

3. "Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это обстоятельство позволяет отделять "высокочастотные" взаимодействия внутри компонентов от "низкочастотной" динамики взаимодействия между компонентами" [10].

Это различие внутрикомпонентных и межкомпонентных взаимодействий обуславливает разделение функций между частями системы и дает возможность относительно изолированно изучать каждую часть.

Как мы уже говорили, многие сложные системы организованы достаточно экономными средствами. Поэтому Саймон приводит следующий признак сложных систем:

4. " Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных" [11].

Иными словам и, разные сложные системы содержат одинаковые структурные части. Эти части могут использовать общие более мелкие компоненты, такие как клетки, или более крупные структуры, типа сосудистых систем, имеющиеся и у растений, и у животных.

Выше мы отмечали, что сложные системы имеют тенденцию к развитию во времени. Саймон считает, что сложные системы будут развиваться из простых гораздо быстрее, если для них существуют устойчивые промежуточные формы [12]. Гэлл [13] выражается более эффектно:

5. "Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы".

В процессе развития системы объекты, первоначально рассматривавшиеся как сложные, становятся элементарными, и из них строятся более сложные системы. Более того, невозможно сразу правильно создать элементарные объекты: с ними надо сначала повозиться, чтобы больше узнать о реальном поведении системы, и затем уже совершенствовать их.


Найдите хоть один из них в РЕЛЯЦИОННОЙ и нормализованной базе данных.

Нафига тогда приплетать ООП, к языку ЗАПРОСОВ для реляционной БД ?

ООП предназначено в первую очередь уменьшить сложность систем...

Реляционные базы данныхи и SQL, аналогично уменьшить сложность, за счет замены сети и иерархии (есть/были еще сетевые, иерархические СУБД) на таблицы и отношения между таблицами.

В настоящий же момент, зачем-то пытаются наоборот, увеличить сложность системы.


В общем, почти как трусы и крестик. Отсюда и образуются два координально разных подход к скрещиванию ООП и Реляционных Баз данных:

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

2. ООП-сериализационный - сделать табличку ID, Object и в Object запихать все данные объекта. В XML, Json'е или вообще бинари. А потом удивляться, что реляционная БД плохо работают. Точнее, что разница между реляционной БД и обычным текстовым файлом становится чуть больше, чем ни какая. В крайнем случае, вполне можно и key - value БД обойтись.

Ну и разные попытки скрестить ежа и удава... Только IMHO до сих пор получается колючая проволока.
...
Рейтинг: 0 / 0
26.06.2017, 09:13
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477469
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Изопропил
Участник
Leonid Kudryavtsevа CSS - это даже не language
полноценный формальный язык
...
Рейтинг: 0 / 0
26.06.2017, 09:33
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477476
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
Дядька с усами и часамиГоспода, господа!
(звон председательского колокольчика)
Попрошу не отклоняться от темы!

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

Плюсы такие:
1. Для написания ИС нужно в 2-3 раза меньше кода, потому что не нужно программировать отдельно клиента, отдельно сервер, и налаживать между ними. Соответственно меньше времени на написание, дешевле.
2. Производительность выше существенно, по предварительной оценке на пару порядков. потому что нет трафика между хранящей и обрабатывающей частью системы. Плюс, как в СУБД остается групповая обработка данных.
3. Гибкость системы выше. Простая архитектура, проще внедрять, проще модифицировать. Там есть еще совсем новые возможности по модификации, которые повышают гибкость.
4. Ничего нового для разработчиков практически нет. Используются всем известные методы и подходы. Опытный программист поймет как с этим работать за полдня.

Я в общем понимаю общий психоз на тему "все придумано до нас" и "ты че, самый умный", привычное отношение, но так же привычно что оно кардинально меняется при полном понимании того что предлагается.
...
Рейтинг: 0 / 0
26.06.2017, 09:50
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477483
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
Leonid Kudryavtsevвадятебе просто хочется пов...ся, в любом случае необходимо указывать имя субд mssql, mysql, fb,....
и этим будет сказаны все языковые тонкости и различия sql.

Да нет языковых тонкостей

SQL (Select) для программирования (написания кода) не предназначен. И Select изначально предназначен исключительно как язык доступа к нормализованным реляционным данным, представленный в виде нормализованных табличек и описания отношений между ними.

Для программирования сторед процедур предназначены языки ПРОГРАММИРОВАНИЯ.

В последних, проблем с ООП нет как класс. Ну хочешь ООП, ну создай себе классы хотья на Java, хоть на PL/SQL. В чем-пробема?

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

Специально нашел Гради Буча "Объектно ориентированный анализ и проектирование". На 3-ей же страницы

 

Пять признаков сложной системы

Исходя из такого способа изучения, можно вывести пять общих признаков любой сложной системы. Основываясь на работе Саймона и Эндо, Куртуа предлагает следующее наблюдение [7]:

1. "Сложные системы часто являются иерархическими и состоят из взаимозависимых подсистем, которые в свою очередь также могут быть разделены на подсистемы, и т.д., вплоть до самого низкого уровням."

Саймон отмечает: "тот факт, что многие сложные системы имеют почти разложимую иерархическую структуру, является главным фактором, позволяющим нам понять, описать и даже "увидеть" такие системы и их части" [8]. В самом деле, скорее всего, мы можем понять лишь те системы, которые имеют иерархическую структуру.

Важно осознать, что архитектура сложных систем складывается и из компонентов, и из иерархических отношений этих компонентов. Речтин отмечает: "Все системы имеют подсистемы, и все системы являются частями более крупных систем... Особенности системы обусловлены отношениями между ее частями, а не частями как таковыми" [9].

Что же следует считать простейшими элементами системы? Опыт подсказывает нам следующий ответ:

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

Низший уровень для одного наблюдателя может оказаться достаточно высоким для другого.

Саймон называет иерархические системы разложимыми, если они могут быть разделены на четко идентифицируемые части, и почти разложимыми, если их составляющие не являются абсолютно независимыми. Это подводит нас к следующему общему свойству всех сложных систем:

3. "Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это обстоятельство позволяет отделять "высокочастотные" взаимодействия внутри компонентов от "низкочастотной" динамики взаимодействия между компонентами" [10].

Это различие внутрикомпонентных и межкомпонентных взаимодействий обуславливает разделение функций между частями системы и дает возможность относительно изолированно изучать каждую часть.

Как мы уже говорили, многие сложные системы организованы достаточно экономными средствами. Поэтому Саймон приводит следующий признак сложных систем:

4. " Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных" [11].

Иными словам и, разные сложные системы содержат одинаковые структурные части. Эти части могут использовать общие более мелкие компоненты, такие как клетки, или более крупные структуры, типа сосудистых систем, имеющиеся и у растений, и у животных.

Выше мы отмечали, что сложные системы имеют тенденцию к развитию во времени. Саймон считает, что сложные системы будут развиваться из простых гораздо быстрее, если для них существуют устойчивые промежуточные формы [12]. Гэлл [13] выражается более эффектно:

5. "Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы".

В процессе развития системы объекты, первоначально рассматривавшиеся как сложные, становятся элементарными, и из них строятся более сложные системы. Более того, невозможно сразу правильно создать элементарные объекты: с ними надо сначала повозиться, чтобы больше узнать о реальном поведении системы, и затем уже совершенствовать их.


Найдите хоть один из них в РЕЛЯЦИОННОЙ и нормализованной базе данных.

Нафига тогда приплетать ООП, к языку ЗАПРОСОВ для реляционной БД ?

ООП предназначено в первую очередь уменьшить сложность систем...

Реляционные базы данныхи и SQL, аналогично уменьшить сложность, за счет замены сети и иерархии (есть/были еще сетевые, иерархические СУБД) на таблицы и отношения между таблицами.

В настоящий же момент, зачем-то пытаются наоборот, увеличить сложность системы.


В общем, почти как трусы и крестик. Отсюда и образуются два координально разных подход к скрещиванию ООП и Реляционных Баз данных:

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

2. ООП-сериализационный - сделать табличку ID, Object и в Object запихать все данные объекта. В XML, Json'е или вообще бинари. А потом удивляться, что реляционная БД плохо работают. Точнее, что разница между реляционной БД и обычным текстовым файлом становится чуть больше, чем ни какая. В крайнем случае, вполне можно и key - value БД обойтись.

Ну и разные попытки скрестить ежа и удава... Только IMHO до сих пор получается колючая проволока.

Эээх))) Хотел было поизголяться, ибо тут есть над чем, но не буду, а то всех распугаю)))

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

Иначе вся бизнес-логика давно уже жила бы в СУБД, ибо с точки зрения архитектуры систем это дает множество преимуществ, которые я описал выше.
...
Рейтинг: 0 / 0
26.06.2017, 09:57
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477484
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Если ближе к теме топика, то аналогично...

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

Когда же пытаются простые (относительно) задачи, сделать многослойными "что бы было", приходим к тому, что имеем. Куча разных слоев, своя парадигма и язык программирование на каждом из слое (SQL, Java, HTML, CSS, JavaScript) и full stack разработчика, у которого голова от всего этого пухнет...

Если он хорошо знает SQL и PL/SQL, он радостно начинает лабать сайты на Oracle HTML-картридже в духе бесконечно лапши из println'ов, от которой любому верстальщику, хоть раз видевшему ASP, PHP, JSP становится дурно.

Если он хорошо знает HTML и JavaScript, то радостно все на них и делает, А всякие AJAX и REST'ы максимум, что бы SELECT в БД выполнить.

Это, разумеется, крайние случае.


Параллельно, не прекращаются попытки запихать таки ежа в рот удаву. При этому, изначально, ежик был мышкой. Которую сначала специально (!) превращают в ежа (!), а потом уже в виде ежа и пасть удаву и запихивают.

95% прикладных систем для БД, на экране содержит.... таблички! обычные таблички!

95% задачи прикладной системы: бизнес-объекты и бизнес-задачу (о сложности которой и говорил Гради Буч) преобразовать в GUI. Что же мы делаем?

1) На HTML рисуем табличку, AJAX'ом кидаем запрос на сервер приложения
2) Тут, зачем-то, преобразовываем ее из вида ПРОСТОЙ таблички в вид СЛОЖНЫХ ООП-объектов со все кучей сложных бизнес-отношений между ними (а нам для отображения на экране не пофиг?).
3) Начинаем сложные иерархические данные (точнее даже сетевые), пытаться пропихнуть в реляционную СУБД. Хотя, изначально, пользователь хотел всего лишь табличку увидеть.

В реальной системе (!) Oracle CC&B, только диву давался. Сколько народ не нужных преобразований делает.

Табличка на экране -> Json -> XML -> коллекции классов -> Hibernate -> DAO, Copy Book'и -> табличка в реляционной СУБД

Можно того же Гради Буча процитировать (страничкой ранее)
 

Почему программному обеспечению присуща сложность?

Как говорит Брукс, "сложность программного обеспечения - отнюдь не случайное его свойство" [3]. Сложность вызывается четырьмя основными причинами:

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

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

IMHO & AFAIK
...
Рейтинг: 0 / 0
26.06.2017, 09:58
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477488
просто я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
просто я
Гость
МурычДядька с усами и часамиГоспода, господа!
(звон председательского колокольчика)
Попрошу не отклоняться от темы!

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

Плюсы такие:
1. Для написания ИС нужно в 2-3 раза меньше кода, потому что не нужно программировать отдельно клиента, отдельно сервер, и налаживать между ними. Соответственно меньше времени на написание, дешевле.
2. Производительность выше существенно, по предварительной оценке на пару порядков. потому что нет трафика между хранящей и обрабатывающей частью системы. Плюс, как в СУБД остается групповая обработка данных.
3. Гибкость системы выше. Простая архитектура, проще внедрять, проще модифицировать. Там есть еще совсем новые возможности по модификации, которые повышают гибкость.
4. Ничего нового для разработчиков практически нет. Используются всем известные методы и подходы. Опытный программист поймет как с этим работать за полдня.

Я в общем понимаю общий психоз на тему "все придумано до нас" и "ты че, самый умный", привычное отношение, но так же привычно что оно кардинально меняется при полном понимании того что предлагается.
упс, если с 0, возможно...
но если пришел, а там уже крутят несколько/МНОГО оч разных СУБД и с трафиком между ними, хранением и обработкой и ломать ничего нельзя?
...
Рейтинг: 0 / 0
26.06.2017, 10:01
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477490
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
МурычДядька с усами и часамиГоспода, господа!
(звон председательского колокольчика)
Попрошу не отклоняться от темы!

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

Плюсы такие:
1. Для написания ИС нужно в 2-3 раза меньше кода, потому что не нужно программировать отдельно клиента, отдельно сервер, и налаживать между ними. Соответственно меньше времени на написание, дешевле.
2. Производительность выше существенно, по предварительной оценке на пару порядков. потому что нет трафика между хранящей и обрабатывающей частью системы. Плюс, как в СУБД остается групповая обработка данных.
3. Гибкость системы выше. Простая архитектура, проще внедрять, проще модифицировать. Там есть еще совсем новые возможности по модификации, которые повышают гибкость.
4. Ничего нового для разработчиков практически нет. Используются всем известные методы и подходы. Опытный программист поймет как с этим работать за полдня.

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

Человек пишет реальное приложение и интересуется сравнением двух реальных архитектур.
А Вы ему: а давайте пофантазируем о сферическом коне в вакууме :)
...
Рейтинг: 0 / 0
26.06.2017, 10:02
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477495
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Мурыч,

Все нормально, только ООП туда приплетать не надо ) Максимум модульность.

Кстати статья на хабре недавняя про подобную реализацию на pg/plsql
https://habrahabr.ru/company/pgdayrussia/blog/326758/
...
Рейтинг: 0 / 0
26.06.2017, 10:09
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477498
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
skyANAМурычпропущено...


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

Плюсы такие:
1. Для написания ИС нужно в 2-3 раза меньше кода, потому что не нужно программировать отдельно клиента, отдельно сервер, и налаживать между ними. Соответственно меньше времени на написание, дешевле.
2. Производительность выше существенно, по предварительной оценке на пару порядков. потому что нет трафика между хранящей и обрабатывающей частью системы. Плюс, как в СУБД остается групповая обработка данных.
3. Гибкость системы выше. Простая архитектура, проще внедрять, проще модифицировать. Там есть еще совсем новые возможности по модификации, которые повышают гибкость.
4. Ничего нового для разработчиков практически нет. Используются всем известные методы и подходы. Опытный программист поймет как с этим работать за полдня.

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

Человек пишет реальное приложение и интересуется сравнением двух реальных архитектур.
А Вы ему: а давайте пофантазируем о сферическом коне в вакууме :)

Ну да, согласен, наверное слегка не туда занесло. Хотя я как раз про сравнения архитектур... просто зашел издалека)) но если человек сейчас пишет, то конечно зря. Если бы в агусте-сентябре, мог бы и нас попробовать. Дядька, Вы когда писать собираетесь?
...
Рейтинг: 0 / 0
26.06.2017, 10:10
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477500
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglМурыч,

Все нормально, только ООП туда приплетать не надо ) Максимум модульность.

Кстати статья на хабре недавняя про подобную реализацию на pg/plsql
https://habrahabr.ru/company/pgdayrussia/blog/326758/

Нет, не похоже. почти во первых строках про аппликейшн сервер.
...
Рейтинг: 0 / 0
26.06.2017, 10:14
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477504
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Мурыч....
Иначе вся бизнес-логика давно уже жила бы в СУБД, ибо с точки зрения архитектуры систем это дает множество преимуществ, которые я описал выше.
Во многих системах вполне себе и живет. Давно и успешно.

Если на разных уровнях системы один и тот же язык (например Oracle Forms: PL/SQL на клиенте или апп.сервер и PL/SQL в СУБД), то где живет бизнес-логика, вообще риторический вопрос. Т.к. в ряде случаев, ее можно просто Copy/Past с клиента на сервер перенести.

МурычТак и здесь, есть инновация, которая позволяет гармонично скрестить ООП и реляционную модель
Все попытки, которые видел до этого, явно удав и ежик

Требование реляционной модели - нормализация данных.

Один из принципов ООП объекта, как меня учили, - "инкапсуляция", т.е. совмещения данных об объекте и его поведение в одном месте

Как минимум, это друг другу противоречит. AFAIK

Те ООП расширения, которые видны, или:
1. попытки денормализовать данные на уровне самого SQL. (всякие вложенные объекты, XML, XPath, JSon и так далее)
2. попытка программистов заинкапсулировать логику поиска данных в объекте - прощай SQL (Query Language), да здравствуют циклы и PL (Procedural/Program Language).

IMHO & AFAIK
...
Рейтинг: 0 / 0
26.06.2017, 10:20
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477507
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
МурычskyANAпропущено...

Ничего себе не отклоняетесь.

Человек пишет реальное приложение и интересуется сравнением двух реальных архитектур.
А Вы ему: а давайте пофантазируем о сферическом коне в вакууме :)

Ну да, согласен, наверное слегка не туда занесло. Хотя я как раз про сравнения архитектур... просто зашел издалека)) но если человек сейчас пишет, то конечно зря. Если бы в агусте-сентябре, мог бы и нас попробовать. Дядька, Вы когда писать собираетесь?
И сколько вы уже существуете на рынке, чтобы вас пробовать? Сколько лет?
...
Рейтинг: 0 / 0
26.06.2017, 10:23
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477508
Vladimir Baskakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir Baskakov
Участник
МурычSiemarglМурыч,

ООП попендикулярно сиквелу. Разные парадигмы т.е

А продвинутую логику в базе - пожалуйста pl/sql, pl/pgsql, на худой конец psql, а хочется объектных извращений - кашаскрипт

Да знаю я про этот импеданс мисматч, но не вечен же он. Раньше думали что земля плоская. И хочется объектных, но не извращений.

Да в общем не о том речь. Импеданс, не импеданс, не имеет значения. Я собственно спросил о том что если в sql появятся ооп возможности, сравнимые с с++, или даже более мощные, и будет возможность для хранения и обработки данных использовать только реляционную субд, и отказаться от аппликейшн сервера, будет ли это кому-то интересно?

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

Когда появятся тогда и поговорим.... пока же не появились? Вот и посмотрим на причины - почему.

Объект.... коллекция объектов? похожа на таблицу. ну так, примерно. наследование допустим - внешний ключ. Каждый потомок является еще и родителем. ...... иииии? собственно что.
...
Рейтинг: 0 / 0
26.06.2017, 10:25
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477516
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
Leonid KudryavtsevМурыч....
Иначе вся бизнес-логика давно уже жила бы в СУБД, ибо с точки зрения архитектуры систем это дает множество преимуществ, которые я описал выше.
Во многих системах вполне себе и живет. Давно и успешно.

Если на разных уровнях системы один и тот же язык (например Oracle Forms: PL/SQL на клиенте или апп.сервер и PL/SQL в СУБД), то где живет бизнес-логика, вообще риторический вопрос. Т.к. в ряде случаев, ее можно просто Copy/Past с клиента на сервер перенести.

МурычТак и здесь, есть инновация, которая позволяет гармонично скрестить ООП и реляционную модель
Все попытки, которые видел до этого, явно удав и ежик

Требование реляционной модели - нормализация данных.

Один из принципов ООП объекта, как меня учили, - "инкапсуляция", т.е. совмещения данных об объекте и его поведение в одном месте

Как минимум, это друг другу противоречит. AFAIK

Те ООП расширения, которые видны, или:
1. попытки денормализовать данные на уровне самого SQL. (всякие вложенные объекты, XML, XPath, JSon и так далее)
2. попытка программистов заинкапсулировать логику поиска данных в объекте - прощай SQL (Query Language), да здравствуют циклы и PL (Procedural/Program Language).

IMHO & AFAIK

Ну хорошо, нельзя скрестить ужа и ежа, это я признаю. Но вот реляционную модель и ООП можно. Просто раньше это пытались, как Вы совершенно справедливо заметили, делать неправильно. Но мы поняли как правильно, и скрестили. Что же теперь делать? )) Я понимаю что трудно в это поверить, но рано или поздно придется. )) Ну не знаю, можем в принципе даже рассказать как это делается. И даже прятаться не будем, можем по скайпу например показать презу, если найдутся желающие.
...
Рейтинг: 0 / 0
26.06.2017, 10:33
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477520
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Vladimir Baskakov,

А внутри объекта - коллекция других (разнотипных, но родственных, объектов) - и все, приехали.
Нормально в сиквел уже не засунешь.
...
Рейтинг: 0 / 0
26.06.2017, 10:36
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477523
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
skyANAМурычпропущено...


Ну да, согласен, наверное слегка не туда занесло. Хотя я как раз про сравнения архитектур... просто зашел издалека)) но если человек сейчас пишет, то конечно зря. Если бы в агусте-сентябре, мог бы и нас попробовать. Дядька, Вы когда писать собираетесь?
И сколько вы уже существуете на рынке, чтобы вас пробовать? Сколько лет?

Ну, кому важнее сколько лет на рынке, тот ничего и не пробует, если кому-то нужен конкретный набор преимуществ, то можно и попробовать. Я в принципе понимаю что 90% населения не нужно Таити.
...
Рейтинг: 0 / 0
26.06.2017, 10:38
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477527
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
МурычskyANAпропущено...

И сколько вы уже существуете на рынке, чтобы вас пробовать? Сколько лет?

Ну, кому важнее сколько лет на рынке, тот ничего и не пробует, если кому-то нужен конкретный набор преимуществ, то можно и попробовать. Я в принципе понимаю что 90% населения не нужно Таити.
Да большинству важно :) Попробовать-то попробуют, только вот крупных контрактов не будет, пока не убедятся, что вы не развалитесь через год.
...
Рейтинг: 0 / 0
26.06.2017, 10:40
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477529
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
Vladimir Baskakov
Когда появятся тогда и поговорим.... пока же не появились? Вот и посмотрим на причины - почему.

Объект.... коллекция объектов? похожа на таблицу. ну так, примерно. наследование допустим - внешний ключ. Каждый потомок является еще и родителем. ...... иииии? собственно что.

Ну да, не появилось. Но не так и далеко.
почему тоже понятно, потому что как справедливо говорилось попытались в свое время натянуть ужа не ежа в ОРСУБД, а там надо просто применить другой подход. В общем, надо знать куда ударить.
Детали обсуждать не буду, не интересно, если давать то полную картину.
...
Рейтинг: 0 / 0
26.06.2017, 10:42
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477532
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglVladimir Baskakov,

А внутри объекта - коллекция других (разнотипных, но родственных, объектов) - и все, приехали.
Нормально в сиквел уже не засунешь.

Не гадайте на кофейной гуще, говорюж, мы готовы рассказать, и гадать не придется.
...
Рейтинг: 0 / 0
26.06.2017, 10:44
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477535
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
skyANAМурычпропущено...


Ну, кому важнее сколько лет на рынке, тот ничего и не пробует, если кому-то нужен конкретный набор преимуществ, то можно и попробовать. Я в принципе понимаю что 90% населения не нужно Таити.
Да большинству важно :) Попробовать-то попробуют, только вот крупных контрактов не будет, пока не убедятся, что вы не развалитесь через год.

Посмотрим, чего гадать. Все кому мы показали воспринимают позитивно, поэтому крупные - не крупные, но что-то будет. А дальше будем смотреть.
...
Рейтинг: 0 / 0
26.06.2017, 10:47
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477545
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
skyANAМурычпропущено...


Ну да, согласен, наверное слегка не туда занесло. Хотя я как раз про сравнения архитектур... просто зашел издалека)) но если человек сейчас пишет, то конечно зря. Если бы в агусте-сентябре, мог бы и нас попробовать. Дядька, Вы когда писать собираетесь?
И сколько вы уже существуете на рынке, чтобы вас пробовать? Сколько лет?
Короче понятно стало после небольшого исследования - Мурый пытается "привлечь инвесторов" к своему мыльному пузырю rxo-project.com, который с 2013г и до сих пор ничего не создал реального.

Все, финита. Много мата.
...
Рейтинг: 0 / 0
26.06.2017, 10:58
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477546
Vladimir Baskakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir Baskakov
Участник
МурычSiemarglVladimir Baskakov,

А внутри объекта - коллекция других (разнотипных, но родственных, объектов) - и все, приехали.
Нормально в сиквел уже не засунешь.

Не гадайте на кофейной гуще, говорюж, мы готовы рассказать, и гадать не придется.

Так расскажите уже, не затягивайте МХАТовскую паузу..... ну или если секретно то не расскажите.....
...
Рейтинг: 0 / 0
26.06.2017, 10:59
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477548
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Даже не знаю, может за такое надо банить? Спам, реклама, секты
...
Рейтинг: 0 / 0
26.06.2017, 10:59
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477555
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
МурычskyANAпропущено...

Да большинству важно :) Попробовать-то попробуют, только вот крупных контрактов не будет, пока не убедятся, что вы не развалитесь через год.

Посмотрим, чего гадать. Все кому мы показали воспринимают позитивно, поэтому крупные - не крупные, но что-то будет. А дальше будем смотреть.
Смотрите конечно. Потом расскажете свои историю успеха.

P.S.: воспринимать позитивно и обосновать экономический эффект и внедрить в продакшн - несколько разные вещи :)
...
Рейтинг: 0 / 0
26.06.2017, 11:09
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477570
просто я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
просто я
Гость
да, все как на sql.ru - за....ли, за....ли чужую тему, за...цы
...
Рейтинг: 0 / 0
26.06.2017, 11:24
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477572
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
SiemarglskyANAпропущено...

И сколько вы уже существуете на рынке, чтобы вас пробовать? Сколько лет?
Короче понятно стало после небольшого исследования - Мурый пытается "привлечь инвесторов" к своему мыльному пузырю rxo-project.com, который с 2013г и до сих пор ничего не создал реального.

Все, финита. Много мата.

Ух ты, зацепило видимо, раз было расследование)
Во первых инвесторы мне не нужны, у меня они есть.
Во вторых, отчитываюсь по прошедшему периоду:

В 13м вышли на рынок с технологией, рассчитывая продать ее СУБД вендорам.
Подписали лицензионные соглашения с Открытыми Информационными Технологиями, если кто в курсе у них СУБД Хайтек
Подписали лицензионное соглашение с РЕЛЭКСОМ, ну тут уж про ЛИНТЕР наверное знают все.
Но устали честно говоря ждать пока они внедрят, поэтому начали делать сами в FB3.

Кроме того проходили две экспертизы в Майкрософт:
1. В Украинском, по результатам нас звали в Киевский бизнес-инкубатор EastLabs, но там у них условия драконовские, да и было это в 14-м, уже буча там начиналась, мы не поехали.
2. в Российском. были по результатам у них на запуске Сиквел сервера в качестве партнеров в 14-м году, но там сильно все заформализованно, нужны бизнес-результаты, чтобы нас передали дальше.

В общем, не скажу что мега результаты, но это нормально. Собственно и поменяли бизнес-модель и стали внедрять в FB чтобы расширить круг потенциальных клиентов. Совсем уж нахаляву не прокатило)) Да.. а дело это не быстрое, поэтому собсно и с 2013 года.
Вот, я ничего не скрываю.

Мне вот интересно другое, причины того что народ не ищет возможностей для себя, а пытается не дать другим? Ну сделайте что нибудь свое, и дай бог чтобы вас поддержали.) Я вас гнобить не буду точно, обещаю))
...
Рейтинг: 0 / 0
26.06.2017, 11:24
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477575
Мурыч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мурыч
Гость
просто яда, все как на sql.ru - за....ли, за....ли чужую тему, за...цы

Ладно, правда не буду здесь больше писать, свою тему открою.
...
Рейтинг: 0 / 0
26.06.2017, 11:26
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477741
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
МурычНу сделайте что нибудь свое, и дай бог чтобы вас поддержали.) Я вас гнобить не буду точно, обещаю))
В плане своё? Вы владелец компании?
...
Рейтинг: 0 / 0
26.06.2017, 14:33
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477796
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
почитал
http://rxo-project.com/wp-content/uploads/2013/03/GrigorievOnImpedanceRU.pdf

мне, в принципе, идея понравилась. Не очень понятно, насколько востребовано в мирных целях, но сильно бредовой не выглядит.

Читал наискось, не вникая. Как я понял, главная идея разобрать классы по атрибутам, а потом "собрать" их обратно из получившегося хлама.
(или реализуем атрибут как STORED, или как отношение SELECT, или как процедурный код )

В общем, IMHO вполне жизненно. По крайне мере, как замена EAV.

Ну и в эпоху популярности скриптовых языков, вполне может найти своих поклонников.
...
Рейтинг: 0 / 0
26.06.2017, 16:11
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39477992
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
Leonid Kudryavtsev,

твои разделения - правильные, но страдают одним - описывают крайности. истина всё же по середине...
надо использовать и оба подхода даже в одном проекте, главное добиваться качества системы, а не следования кем-то придуманных принцЫпов.
тогда и удав счастлив и и ёжик бегать в тумане.
...
Рейтинг: 0 / 0
26.06.2017, 20:19
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39478023
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
вадятвои разделения - правильные, но страдают одним - описывают крайности. истина всё же по середине...
надо использовать и оба подхода даже в одном проекте, главное добиваться качества системы, а не следования кем-то придуманных принцЫпов.
тогда и удав счастлив и и ёжик бегать в тумане.

Просто не надо пытаться впихнуть в невпихуемое

Я так взъелся именно из за попыток ООП в реляционный SQL (Query Language) впихнуть. Даром он там не нужен. Использовать ООП в языках программирования, в общем то, никаких проблем. (хоть pl/sql, хоть java).

Из всех ООП расширений, максимум денормалиция результатов запроса (агрегировании нескольких наборов данных в одно поле) как костыль, для уменьшения трафика межу приложением и БД. Все остальное IMHO не жизнеспособный шлак.

А особенно очень печалит, когда сначала над мышами жутко издеваются, превращая их в ежиков.... а уже потом в удава впихивают.... И тех и других жалко. И мыши-ежи мучаются и удав.

Если уж хочется скрестить ООП и БД, то тогда логичнее кажется брать/делать сетевую СУБД. Давать доступ к информации как к стримам, передавать в СУБД лямбду, получать результат. Только с существующими РСУБД такой финт ушами вряд ли пройдет.
...
Рейтинг: 0 / 0
26.06.2017, 22:20
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39479024
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
Leonid Kudryavtsevпочитал
http://rxo-project.com/wp-content/uploads/2013/03/GrigorievOnImpedanceRU.pdf

мне, в принципе, идея понравилась. Не очень понятно, насколько востребовано в мирных целях, но сильно бредовой не выглядит.

Читал наискось, не вникая. Как я понял, главная идея разобрать классы по атрибутам, а потом "собрать" их обратно из получившегося хлама.
 (или реализуем атрибут как STORED, или как отношение SELECT, или как процедурный код )

В общем, IMHO вполне жизненно. По крайне мере, как замена EAV.

Ну и в эпоху популярности скриптовых языков, вполне может найти своих поклонников.

ты все неправильно понял. прочитай статью еще раз.

автор (страдающий натужным словесным недержанием) сначала доказывает, что между ОО и реляционной моделью прямое соотвествие (а чего бы его там не было, 1:M, M:1 и там и там, отличается лишь реализация), а в конце скатывается к тому, что уже десятки лет назад пытались срелать в ОО базах данных (тот-же Oracle) - расширить синтаксис SQL, чтоб можно было джойнить через точку, писать нечто вроде SELECT document.contract.contract_date FROM document
вместо SELECT contract.contract_date FROM contract, document WHERE document.contract_id = contract.contract_id
...
Рейтинг: 0 / 0
28.06.2017, 13:45
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39479033
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
Leonid Kudryavtsevвадятвои разделения - правильные, но страдают одним - описывают крайности. истина всё же по середине...
надо использовать и оба подхода даже в одном проекте, главное добиваться качества системы, а не следования кем-то придуманных принцЫпов.
тогда и удав счастлив и и ёжик бегать в тумане.

Просто не надо пытаться впихнуть в невпихуемое

Я так взъелся именно из за попыток ООП в реляционный SQL (Query Language) впихнуть. Даром он там не нужен. Использовать ООП в языках программирования, в общем то, никаких проблем. (хоть pl/sql, хоть java).

Из всех ООП расширений, максимум денормалиция результатов запроса (агрегировании нескольких наборов данных в одно поле) как костыль, для уменьшения трафика межу приложением и БД. Все остальное IMHO не жизнеспособный шлак.

А особенно очень печалит, когда сначала над мышами жутко издеваются, превращая их в ежиков.... а уже потом в удава впихивают.... И тех и других жалко. И мыши-ежи мучаются и удав.

Если уж хочется скрестить ООП и БД, то тогда логичнее кажется брать/делать сетевую СУБД. Давать доступ к информации как к стримам, передавать в СУБД лямбду, получать результат. Только с существующими РСУБД такой финт ушами вряд ли пройдет.

все там нужно. просто в том-же Oracle реализация, мягко говоря, оказалась неудачная и тормозная, плюс поддержка утилитами и прочая обратная совместимость оказалась недоделана, потому и не взлетело.

а отдельно взятые "чистые" OORDBMS оказались и вовсе никому не нужны - никому не охота отлавливать глюки в продакшине аля Иллюстра, надежность важнее синтаксиса.
...
Рейтинг: 0 / 0
28.06.2017, 13:52
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39479713
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
dbpatch,
Вы либо статью не вчитали, либо с Ораклом и тд не знакомы. В оракле "таблица = классу" и "структура объекта класса = схема таблицы". Нафига такие классы, которые почти таблицы- не очень понятно. В статье же предлагается строить классы из типов, допустимых в РМД (т.е. из скаляров и отношений), а таблицы, наоборот, из типов доступных в ОО части (скаляры и ссылочные типы(тоже скаляры)), т.е. строго "таблица != класс" (про это еще Дейт много писал, но он шел только в одну сторону, от скаляров к таблицам). Кроме того, там по ссылкам есть статьи, где строго доказано, что система построенная по этому принципу остается строго реляционной. В при этом классы и таблицы могут сосуществовать в единой схеме данных, т.е. в RxO можно строить сложные гетерогенные схемы данных, гораздо более выразительные, чем просто табличные (как сейчас в современный РСУБД).

Вообще, такой невдумчивый дилетантизм "вот оракл 20 лет назад с объектами ковырялся, у них ничего не получилось, значит и тут - фигня" - очень большая проблема, и каждый раз заново разницу приходится разжевывать.
...
Рейтинг: 0 / 0
29.06.2017, 14:47
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39479724
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
dbpatchавтор (страдающий натужным словесным недержанием) сначала доказывает, что между ОО и реляционной моделью прямое соотвествие

это, собственно, и доказывает, что статью вы не читали внимательно.

цитата из стаьтиСуществует явная аналогия между действиями , выполняемыми при создании классов и при
описании схемы данных в реляционной БД. И там и там имеются наборы базовых скалярных
типов. И там и там используются синтаксически схожие конструкторы, позволяющие описать
сложные структуры классов (используемых в ОО программе) или схемы отношений
(составляющих реляционную БД). Возможно, именно это внешнее сходство является причиной
того, что ОО–программы и реляционные БД воспринимаются как явления одного порядка,
допускающие прямое сравнение.
...
...
...
Таким образом, свойства, присущие реляционным системам данных, никак не связаны со
свойствами объектно-ориентированных систем программирования. Несмотря на возможное
внешнее сходство, эти системы являются ортогональными .

А все. что Вы называете словесным недержание - описание понятий, нужное, что бы прийти к этому выводу. Но если в голове это не получается удержать, то это не проблемы статьи.
...
Рейтинг: 0 / 0
29.06.2017, 14:58
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39479785
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
U-genedbpatch,
Вы либо статью не вчитали, либо с Ораклом и тд не знакомы. В оракле "таблица = классу" и "структура объекта класса = схема таблицы". Нафига такие классы, которые почти таблицы- не очень понятно. В статье же предлагается строить классы из типов, допустимых в РМД (т.е. из скаляров и отношений), а таблицы, наоборот, из типов доступных в ОО части (скаляры и ссылочные типы(тоже скаляры)), т.е. строго "таблица != класс" (про это еще Дейт много писал, но он шел только в одну сторону, от скаляров к таблицам). Кроме того, там по ссылкам есть статьи, где строго доказано, что система построенная по этому принципу остается строго реляционной. В при этом классы и таблицы могут сосуществовать в единой схеме данных, т.е. в RxO можно строить сложные гетерогенные схемы данных, гораздо более выразительные, чем просто табличные (как сейчас в современный РСУБД).

Вообще, такой невдумчивый дилетантизм "вот оракл 20 лет назад с объектами ковырялся, у них ничего не получилось, значит и тут - фигня" - очень большая проблема, и каждый раз заново разницу приходится разжевывать.

честно говоря, я даже задумался, о чем ты сейчас. скаляры, ссылочные типы, строго реляционной?
ты еще про функциональные зависимости, кортежи и 5НФ задвинь, чтоб туману побольше напустить, обчитавшись Дж.К. Дейта

мысль твоя в чем?

я три раза перечитал твой опус - понял только одно - ты чем-то глубоко возмущен, но незадача - мысль твоя (что именно ты пытаешься доказать) - так и осталась неочевидной.

таблица != класс? ну ясен пончик, в одну таблицу можно материализовать все множество порожденных классов, а можно и вовсе eblobы в JSON запихнуть, и дальше что?

а так там в статье много чего понаписано, из отряда когнитивных диссонансов автора

авторТочно также сопоставление свойств ОО и реляционных систем не имеет смысла – потому что это
ортогональные системы. Тем более такое сопоставление не является основанием для того, что бы
утверждать о их (не)совпадении.

такое бывает всегда, когда в IT набегают теоретизирубщие "сайнтисты" (назвать их учеными нельзя),
никогда в своей жизни ничего не создавшие, да и просто не способные даже сделать какой АРМ "Деканат",
ибо у них же принцип успеха в жизни - "не умеешь сам, учи других, не умеешь учить - учи как надо учить".
...
Рейтинг: 0 / 0
29.06.2017, 15:41
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39479794
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
U-geneА все. что Вы называете словесным недержание - описание понятий, нужное, что бы прийти к этому выводу. Но если в голове это не получается удержать, то это не проблемы статьи.

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

а он первые три листа несет какую-то пургу из намека на проблематику, и даже не пытается четко обозначить суть решаемой проблемы и собственно решение, дочитав до четвертого листа уже трудно вспомнить, о чем речь начиналась

хорошо хоть абзацы пытается ставить (не к месту)

если бы не примеры в конце - статью и вовсе можно было бы отправить в треш как бессмысленную компиляцию фраз
...
Рейтинг: 0 / 0
29.06.2017, 15:47
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39479811
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
dbpatch,

всем не угодить. Редактору odbms.org понравилось - и ладно
...
Рейтинг: 0 / 0
29.06.2017, 16:05
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39479817
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
dbpatchмысль твоя в чем?

Мне кажется, мысль мою лично Вам очень долго придется объяснять, извините.
...
Рейтинг: 0 / 0
29.06.2017, 16:16
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39479923
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
U-genedbpatchмысль твоя в чем?

Мне кажется, мысль мою лично Вам очень долго придется объяснять, извините.

мы живем в XXI веке. если твоя мысль не может быть вписана в пару абзацев - то ее никто не услышит, ибо это уже не мысль, а просто белый шум.

простое же правило, пора бы и осознать
...
Рейтинг: 0 / 0
29.06.2017, 18:40
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39480007
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
dbpatch,
:)
Именно про это я и сказал сегодня
3 абзаца в голове уже не помещается
так и живем
...
Рейтинг: 0 / 0
29.06.2017, 22:29
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39480022
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
U-genedbpatch,
:)
Именно про это я и сказал сегодня
3 абзаца в голове уже не помещается
так и живем

3>2, и то, у тебя было намешано там каши какой-то, начал про одно, перескочил на третье, в итоге сделал вывод про что-то двадцать пятое, про Oracle

я тебе об этом прямо и сказал - соберись, и выдай что-то одно, но по сути
...
Рейтинг: 0 / 0
29.06.2017, 23:26
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39480057
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
U-gene
Участник
ОК, по сути.
dbpatchу тебя было намешано там каши какой-то, начал про одно, перескочил на третье, в итоге сделал вывод про что-то двадцать пятое, про Oracle
это типично. когда буфер маленький (всего 2 абзаца), происходит переполнение и потеря пакетов, смысл теряется. Но это проблемы у приемника.
...
Рейтинг: 0 / 0
30.06.2017, 01:31
| Ответить | Цитировать | Написать  
Клиентское приложение - Сервер Приложений - СУБД
    #39480063
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dbpatch
Участник
U-geneОК, по сути.
dbpatchу тебя было намешано там каши какой-то, начал про одно, перескочил на третье, в итоге сделал вывод про что-то двадцать пятое, про Oracle
это типично. когда буфер маленький (всего 2 абзаца), происходит переполнение и потеря пакетов, смысл теряется. Но это проблемы у приемника.

да ничего не теряется, POSIX manuals к примеру спокойно усваиваются мегабайтными пакетами.

в твоем случае скорее применима аналогия "если пакет битый, и даже с CRC у него проблемы - да, его отсеивает kernel, не пропуская на уровень приложения".

попробуй отправить пакеты с правильной CRC суммой :)
...
Рейтинг: 0 / 0
30.06.2017, 01:49
| Ответить | Цитировать | Написать  
155 сообщений из 155, показаны все 7 страниц
  все  
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Клиентское приложение - Сервер Приложений - СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=16&tid=1340354]:
 0ms
get settings:
 9ms
get forum list:
 18ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 158ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 138ms
get tp. blocked users:
 1ms
others: 227ms
total:  571ms
созд. / загр.: 571ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]