|
|
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Коллеги, а как бы Вы отнеслись к возможности писать ИС (исключая интерфейс) на голом SQL, в который интегрированы полноценные ОО возможности? (Ну.. назовем его , скажем, SQL++ :-) ) Не криво, как в ОРСУБД, а прям нормально, так что удобно, просто и везде применимо? Были бы для Вас какие-то плюсы от этого. Возможность такового предлагаю пока оставить за скобками, просто гипотетический вариант. А? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 13:59 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Мурыч, отрицательно опыт индустрии показал, что это не живет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 14:18 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
SiemarglМурыч, отрицательно опыт индустрии показал, что это не живет Ну да, был такой опыт. Но давайте представим что это живет, тогда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 14:24 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Мурыча как бы Вы отнеслись к возможности писать ИС (исключая интерфейс) на голом SQL Тогда это уже не будет SQL, а будет FUIL. По определению! SQL = Structural Query Language FUIL = Fa...ing User Interface Language На SQL писать интерфейсы, как на английском языке русским матом разговаривать, от всего богатства языка, только shit и double shit останется ((( Пользователи не поймут. А вот на FUIL, писать пользовательские интерфейсы будет очень удобно. Хоть в название языка и 4 буквы, но пользователи сразу после установки программы на компьютер будут понимать, что послали их на 3. И лишних вопросов к службе поддержки у них не возникнет. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 17:02 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevМурыча как бы Вы отнеслись к возможности писать ИС (исключая интерфейс) на голом SQL Тогда это уже не будет SQL, а будет FUIL. По определению! SQL = Structural Query Language FUIL = Fa...ing User Interface Language На SQL писать интерфейсы, как на английском языке русским матом разговаривать, от всего богатства языка, только shit и double shit останется ((( Пользователи не поймут. А вот на FUIL, писать пользовательские интерфейсы будет очень удобно. Хоть в название языка и 4 буквы, но пользователи сразу после установки программы на компьютер будут понимать, что послали их на 3. И лишних вопросов к службе поддержки у них не возникнет. IMHO Да, все что касается интерфейса - святая правда. Но я спрашивал про все кроме интерфейса. А вообще, остроумие - не всегда признак ума, а зачастую и наоборот. Возможно это и не про вас, но всеж поаккуратнее бы вам со своим имхо. Как говорится - береги имхо смолоду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 18:47 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Мурыч,ты зря его так.. он действительно верно обозначил эту ситуацию. твой вариант возможен, но только как демонстрация хитроумности ума... чисто на хранимках можно вывести практически всё ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 20:02 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
вадяМурыч,ты зря его так.. он действительно верно обозначил эту ситуацию. твой вариант возможен, но только как демонстрация хитроумности ума... чисто на хранимках можно вывести практически всё Я человек мира, не шалю, никого не трогаю, починяю примус) Да кто ж спорит то, все проблемы решены, можно сделать что угодно как угодно, вопрос в эффективности. Вот хранимки - удобно? Удобно. Если классы будут в sql нормально жить, тоже ведь будет удобно? Тогда в принципе от аппликейшн сервера можно будет отказаться. Как вам такая перспектива? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 20:20 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
МурычКак вам такая перспектива? бесперспективно. говнокод от данных желательно отделять. данные обычно ценнее и могут быть обработаны разными инструментами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 20:33 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
ИзопропилМурычКак вам такая перспектива? бесперспективно. говнокод от данных желательно отделять. данные обычно ценнее и могут быть обработаны разными инструментами Главное отделять говно от код. Правильно я понял что если будет обеспечена сохранность данных, то перспективно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 20:56 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Мурыч, ООП попендикулярно сиквелу. Разные парадигмы т.е А продвинутую логику в базе - пожалуйста pl/sql, pl/pgsql, на худой конец psql, а хочется объектных извращений - кашаскрипт ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 20:56 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Изопропилговнокод от данных желательно отделять. А почему алгоритмы, обрабатывающие пользовательские цифирьки, являются менее ценными пользовательскими данными , чем сами эти цифирьки? Вот две ситуации 1) цифирьки есть, а алгоритмов нет - это хорошо? 2) алгоритмы хранятся так же надежно, как и цифирьки - это плохо? В конце концов, я могу сказать что "говноцифирьки" тоже есть бгггг. На самом деле, штука в том, что инструменты хранения данных были ориентированы в первую очередь на цифирьки, но не на алгоритмы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 21:15 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
SiemarglМурыч, ООП попендикулярно сиквелу. Разные парадигмы т.е А продвинутую логику в базе - пожалуйста pl/sql, pl/pgsql, на худой конец psql, а хочется объектных извращений - кашаскрипт Да знаю я про этот импеданс мисматч, но не вечен же он. Раньше думали что земля плоская. И хочется объектных, но не извращений. Да в общем не о том речь. Импеданс, не импеданс, не имеет значения. Я собственно спросил о том что если в sql появятся ооп возможности, сравнимые с с++, или даже более мощные, и будет возможность для хранения и обработки данных использовать только реляционную субд, и отказаться от аппликейшн сервера, будет ли это кому-то интересно? Я не обсуждаю возможно это или нет, потому что это отдельный и не маленький разговор, учитывая понятный мне негативный опыт индустрии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 21:16 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Мурычбудет ли это кому-то интересно? кому-то - может быть но критическая масса интересующихся не набралась ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 21:21 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
SiemarglООП попендикулярно сиквелу. Разные парадигмы т.е Именно что перпенжикулярны, ничто не мешает их свести вместе. http://www.odbms.org/2012/08/impedance-mismatch-is-not-an-objects-vs-relations-problem-draft/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 21:22 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Мурыч, Дык ООП в чистом виде устарело. И скрещивается с алгеброй сиквела не очень производительно. Если будет хороший фреймворк для x-sql, то можно его успешно применять и без полноценного ооп-подхода. Например объекты(модули) но без наследования и/или без виртуализации. Только это опять будет тяготеть к 2-звенке со всеми ее достоинствами и --ми. Итого - получится АПЕКС =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 21:47 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
ИзопропилМурычбудет ли это кому-то интересно? кому-то - может быть но критическая масса интересующихся не набралась Ну так это нормально, 90% народа живет по принципу ничего не вижу, ничего не слышу. И это, кстати, тоже нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 22:18 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
SiemarglМурыч, Дык ООП в чистом виде устарело. И скрещивается с алгеброй сиквела не очень производительно. Если будет хороший фреймворк для x-sql, то можно его успешно применять и без полноценного ооп-подхода. Например объекты(модули) но без наследования и/или без виртуализации. Только это опять будет тяготеть к 2-звенке со всеми ее достоинствами и --ми. Итого - получится АПЕКС =) Так то в чистом, а то скрещенное с реляционной моделью, это другая история. Ну так что важнее для вас, то что есть известные вам решения, или потенциальная низкая производительность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 22:26 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
МурычИзопропилпропущено... кому-то - может быть но критическая масса интересующихся не набралась Ну так это нормально, 90% народа живет по принципу ничего не вижу, ничего не слышу. И это, кстати, тоже нормально. Это даже хорошо - меньше конкурентов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 22:27 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
МурычSiemarglМурыч, Дык ООП в чистом виде устарело. И скрещивается с алгеброй сиквела не очень производительно. Если будет хороший фреймворк для x-sql, то можно его успешно применять и без полноценного ооп-подхода. Например объекты(модули) но без наследования и/или без виртуализации. Только это опять будет тяготеть к 2-звенке со всеми ее достоинствами и --ми. Итого - получится АПЕКС =) Так то в чистом, а то скрещенное с реляционной моделью, это другая история. Ну так что важнее для вас, то что есть известные вам решения, или потенциальная низкая производительность? Я использую родные для платформ решения. т.е в данном контексте голый sql. В ущерб своему удобству первичного написания. Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится. (с) Поэтому ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 22:37 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
SiemarglМурычпропущено... Так то в чистом, а то скрещенное с реляционной моделью, это другая история. Ну так что важнее для вас, то что есть известные вам решения, или потенциальная низкая производительность? Я использую родные для платформ решения. т.е в данном контексте голый sql. В ущерб своему удобству первичного написания. Всегда не хватает времени, чтобы выполнить работу как надо, но на то, чтобы ее переделать, время находится. (с) Поэтому УУУх ))) Очень образно Вы выражаетесь))) Вы хотите сказать что используете то что знаете, даже понимая что все это может привести к последующим переработкам и переделкам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 22:48 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Мурыч, Наоборот, под каждую новую для меня инфраструктуру, я смотрю типовые для _этой структуры_ подходы. А пишу я под много чего... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 22:49 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
SiemarglМурыч, Наоборот, под каждую новую для меня инфраструктуру, я смотрю типовые для _этой структуры_ подходы. А пишу я под много чего... Хотите сказать что главное чтобы то чем Вы пользуетесь было типовым решением? Для Вас даже менее важны затраты, производительность и гибкость решения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 23:14 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
Мурыч, можно в хранимке/запросе сформировать данные так, чтоб только вставить в таблицу в браузере, дату в нужном формате, числа красиво сформатировать, даже html тэги добавить....и вывести это одной строкой чтоб передать её в браузер, и вставить командой innerHTML. но это извращение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 23:28 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
МурычSiemarglМурыч, Наоборот, под каждую новую для меня инфраструктуру, я смотрю типовые для _этой структуры_ подходы. А пишу я под много чего... Хотите сказать что главное чтобы то чем Вы пользуетесь было типовым решением? Для Вас даже менее важны затраты, производительность и гибкость решения? Производительность типовых рекомендованных решений "от производителя" высокая. Затраты/гибкость меня волнуют меньше. Предлагаю вместо обсуждений реальных решений Вам вернуться к обсуждению нереалистичного SQL+++ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 23:31 |
|
||
|
Клиентское приложение - Сервер Приложений - СУБД
|
|||
|---|---|---|---|
|
#18+
МурычВот хранимки - удобно? Удобно. Хранимки на SQL написать не возможно в ПРИНЦИПЕ ! Хранимки пишут на каком нибудь языке программирования, а не на SQL. МурычЕсли классы будут в sql нормально жить, тоже ведь будет удобно? Они и так нормально живут. Так же, как нормально живут тексты, видео и любая другая информация закодированная в виде последовательности битиков и байтиков. SELECT mySeriallizedClass FROM myTable WHERE id=:p_id; SiemarglООП попендикулярно сиквелу. Разные парадигмы т.е А продвинутую логику в базе - пожалуйста pl/sql, pl/pgsql, на худой конец psql, а хочется объектных извращений - кашаскрипт +100500 и я о том же.... При чем тут вообще ООП, я полностью не понял. ВикипедияСервер приложений (англ. application server) — это программная платформа (фреймворк), предназначенная для эффективного исполнения процедур (программ, скриптов), на которых построены приложения.... Любая современная СУБД УЖЕ является сервером приложений. При чем тут ООП, SQL... и прочий винегрет, совершенно не понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2017, 23:36 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39477352&tid=1340354]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
166ms |
get topic data: |
8ms |
get forum data: |
1ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
| others: | 209ms |
| total: | 466ms |

| 0 / 0 |
