SB
нет. просто прямой запрос . а может быть из-за того что пользую десплатный постгрес?
Нет. А сколько возвращается примерно, в байтах? Может ограничение где-то стоит. Какие типы полей?
Size: a a a
2020 June 08
IK
а, все понял. просто никонгда не слышал на русском)
YS
```В 100% случаев задачу можно решить без СУБД вообще... но если с тем же качеством — лет этак через 200. ;)
Т.е. у нас тут в отрасли (вообще в программировании, да) куча средств в принципе эквивалентных по выразительной мощности (полнота по Тьюрингу и т.п.). Поэтому "можно решить" — это не то, что в норме имеет значение.```
Словоблудие. Так и не сказали, чем та же MongoDB хуже при правильном проектировании коллекций той же PGSQL. Я много на самом деле занимался разработкой и для того, и для другого. И не знаю чем хуже MongoDB, кроме как есть ряд случаев когда PGSQL выигрывает в скорости за счёт реляции.
```Понимающего что, извините? В некоторых ситуациях лучше ФП, в других — ООП, скорее всего.
Я с этим не спорю. Но в большинстве своём - NoSQL и SQL будут решать +/- одинаково по издержкам, отличаться будет схема хранения. И то, может быть на уровне адаптера к БД. В коде бизнес-логики не должно быть слоя данных ведь.
Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более. Есть задачи где PGSQL будет в разы хуже ArangoDB, верно и обратное. Но это опять же - просто специфика. Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё. А вот инженеры хорошо знающие ещё и NoSQL понимают, что надо отталкиваться от задачи и что реляция очень часто дорого.
Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
ну и да. Так, PGSQL хорошо. Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL. И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Т.е. у нас тут в отрасли (вообще в программировании, да) куча средств в принципе эквивалентных по выразительной мощности (полнота по Тьюрингу и т.п.). Поэтому "можно решить" — это не то, что в норме имеет значение.```
Словоблудие. Так и не сказали, чем та же MongoDB хуже при правильном проектировании коллекций той же PGSQL. Я много на самом деле занимался разработкой и для того, и для другого. И не знаю чем хуже MongoDB, кроме как есть ряд случаев когда PGSQL выигрывает в скорости за счёт реляции.
```Понимающего что, извините? В некоторых ситуациях лучше ФП, в других — ООП, скорее всего.
Паттерн. ООП - это то же ФП по сути. Объект - есть так же функция высшего порядка. Со слов А. Кея - при создании ООП и Smalltalk он брал за основу модель акторов, а они всё же ФП в первую очередь.
Всё, что можно сделать в ООП, может быть написано в ФП. Иногда удобнее ООП, иногда ФП. Но это не значит, что ООП лучше. Он проще, чем ФП, тут да. Джуну ФП будет даваться сложнее. В современных задачах ФП/ООП скорее вкусовщина и квалификация команды.
```Это "синдром" не забивания гвоздей микроскопом. ;) Т.е. RDBMS [намного] лучше решают одни задачи, NoSQL — другие.
Я с этим не спорю. Но в большинстве своём - NoSQL и SQL будут решать +/- одинаково по издержкам, отличаться будет схема хранения. И то, может быть на уровне адаптера к БД. В коде бизнес-логики не должно быть слоя данных ведь.
И это, опять-таки, в норме никому не интересно, см. выше.
Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более. Есть задачи где PGSQL будет в разы хуже ArangoDB, верно и обратное. Но это опять же - просто специфика. Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё. А вот инженеры хорошо знающие ещё и NoSQL понимают, что надо отталкиваться от задачи и что реляция очень часто дорого.
Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
ну и да. Так, PGSQL хорошо. Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL. И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
> Словоблудие.
No you. Если Вы этого не понимаете — пишите всё в машинном коде, не стесняйтесь.
И да, было бы хорошо, если бы Вы не "отмахивались", а писали по существу.
> Паттерн. ООП - это то же ФП по сути.
Хмм... вот это бред так бред, извините. ;) Почитали бы Вы определения того и другого, что ли...
> Объект - есть так же функция высшего порядка.
Ссылку дайте вот на это вот.
> Всё, что можно сделать в ООП, может быть написано в ФП.
"Потрясающе". Вы бы прочитали, что я Вам писал выше, что ли.
> Со слов А. Кея - при создании ООП и Smalltalk он брал за основу модель акторов, а они всё же ФП в первую очередь.
Не нужно приплетать сюда Алана — то, что он имел в виду, и то, что сейчас обычно называют ООП, имеют очень мало общего (не верите — сходите почитайте его объяснения / ответы на вопросы вроде "что Алан Кей имел в виду (vs "современное ООП")?").
> В коде бизнес-логики не должно быть слоя данных ведь
Кто Вам это сказал?
> Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более.
Может, это популярность NoSQL говорит о низкой квалификации большей части "специалистов" в моделировании данных вообще и в реляционной модели в частности? ;)
> Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё.
Потому что "фанатики" с нетерпением ждут, когда же им покажут хоть одну другую математическую модель данных, и подозревают, что NoSQL — это "cнова здорово" набор ad-hoc практик, которые с омерзением выкинули с появлением реляционных СУБД те, кому приходилось тогда есть этот кактус. ;)
> что реляция очень часто дорого.
Реляция — это всего лишь модель данных, Вы это понимаете? Она не может быть "дорогой" в принципе.
> Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
А что я пойму-то? Что выбравшие ElasticSearch не умеют пользоваться PostgreSQL? ;)
Или то, что возможностей PostgreSQL не хватает для каких-то конкретных видов поиска?
> Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL.
Причём тут какие-то "большие компании"? Вы всерьёз считаете вот это вот аргументом... для обоснования хоть чего-то?!
> И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Хмм... о чём, вообще, речь?!
No you. Если Вы этого не понимаете — пишите всё в машинном коде, не стесняйтесь.
И да, было бы хорошо, если бы Вы не "отмахивались", а писали по существу.
> Паттерн. ООП - это то же ФП по сути.
Хмм... вот это бред так бред, извините. ;) Почитали бы Вы определения того и другого, что ли...
> Объект - есть так же функция высшего порядка.
Ссылку дайте вот на это вот.
> Всё, что можно сделать в ООП, может быть написано в ФП.
"Потрясающе". Вы бы прочитали, что я Вам писал выше, что ли.
> Со слов А. Кея - при создании ООП и Smalltalk он брал за основу модель акторов, а они всё же ФП в первую очередь.
Не нужно приплетать сюда Алана — то, что он имел в виду, и то, что сейчас обычно называют ООП, имеют очень мало общего (не верите — сходите почитайте его объяснения / ответы на вопросы вроде "что Алан Кей имел в виду (vs "современное ООП")?").
> В коде бизнес-логики не должно быть слоя данных ведь
Кто Вам это сказал?
> Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более.
Может, это популярность NoSQL говорит о низкой квалификации большей части "специалистов" в моделировании данных вообще и в реляционной модели в частности? ;)
> Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё.
Потому что "фанатики" с нетерпением ждут, когда же им покажут хоть одну другую математическую модель данных, и подозревают, что NoSQL — это "cнова здорово" набор ad-hoc практик, которые с омерзением выкинули с появлением реляционных СУБД те, кому приходилось тогда есть этот кактус. ;)
> что реляция очень часто дорого.
Реляция — это всего лишь модель данных, Вы это понимаете? Она не может быть "дорогой" в принципе.
> Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
А что я пойму-то? Что выбравшие ElasticSearch не умеют пользоваться PostgreSQL? ;)
Или то, что возможностей PostgreSQL не хватает для каких-то конкретных видов поиска?
> Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL.
Причём тут какие-то "большие компании"? Вы всерьёз считаете вот это вот аргументом... для обоснования хоть чего-то?!
> И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Хмм... о чём, вообще, речь?!
IK
Нет. А сколько возвращается примерно, в байтах? Может ограничение где-то стоит. Какие типы полей?
возвращается две даты, аййдишник и имя. остальные данные полностью отсекаются. 128 ,байт.
типы полей - инт, две даты, и строковые остальные. есть еще пару инт
типы полей - инт, две даты, и строковые остальные. есть еще пару инт
МШ
```В 100% случаев задачу можно решить без СУБД вообще... но если с тем же качеством — лет этак через 200. ;)
Т.е. у нас тут в отрасли (вообще в программировании, да) куча средств в принципе эквивалентных по выразительной мощности (полнота по Тьюрингу и т.п.). Поэтому "можно решить" — это не то, что в норме имеет значение.```
Словоблудие. Так и не сказали, чем та же MongoDB хуже при правильном проектировании коллекций той же PGSQL. Я много на самом деле занимался разработкой и для того, и для другого. И не знаю чем хуже MongoDB, кроме как есть ряд случаев когда PGSQL выигрывает в скорости за счёт реляции.
```Понимающего что, извините? В некоторых ситуациях лучше ФП, в других — ООП, скорее всего.
Я с этим не спорю. Но в большинстве своём - NoSQL и SQL будут решать +/- одинаково по издержкам, отличаться будет схема хранения. И то, может быть на уровне адаптера к БД. В коде бизнес-логики не должно быть слоя данных ведь.
Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более. Есть задачи где PGSQL будет в разы хуже ArangoDB, верно и обратное. Но это опять же - просто специфика. Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё. А вот инженеры хорошо знающие ещё и NoSQL понимают, что надо отталкиваться от задачи и что реляция очень часто дорого.
Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
ну и да. Так, PGSQL хорошо. Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL. И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Т.е. у нас тут в отрасли (вообще в программировании, да) куча средств в принципе эквивалентных по выразительной мощности (полнота по Тьюрингу и т.п.). Поэтому "можно решить" — это не то, что в норме имеет значение.```
Словоблудие. Так и не сказали, чем та же MongoDB хуже при правильном проектировании коллекций той же PGSQL. Я много на самом деле занимался разработкой и для того, и для другого. И не знаю чем хуже MongoDB, кроме как есть ряд случаев когда PGSQL выигрывает в скорости за счёт реляции.
```Понимающего что, извините? В некоторых ситуациях лучше ФП, в других — ООП, скорее всего.
Паттерн. ООП - это то же ФП по сути. Объект - есть так же функция высшего порядка. Со слов А. Кея - при создании ООП и Smalltalk он брал за основу модель акторов, а они всё же ФП в первую очередь.
Всё, что можно сделать в ООП, может быть написано в ФП. Иногда удобнее ООП, иногда ФП. Но это не значит, что ООП лучше. Он проще, чем ФП, тут да. Джуну ФП будет даваться сложнее. В современных задачах ФП/ООП скорее вкусовщина и квалификация команды.
```Это "синдром" не забивания гвоздей микроскопом. ;) Т.е. RDBMS [намного] лучше решают одни задачи, NoSQL — другие.
Я с этим не спорю. Но в большинстве своём - NoSQL и SQL будут решать +/- одинаково по издержкам, отличаться будет схема хранения. И то, может быть на уровне адаптера к БД. В коде бизнес-логики не должно быть слоя данных ведь.
И это, опять-таки, в норме никому не интересно, см. выше.
Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более. Есть задачи где PGSQL будет в разы хуже ArangoDB, верно и обратное. Но это опять же - просто специфика. Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё. А вот инженеры хорошо знающие ещё и NoSQL понимают, что надо отталкиваться от задачи и что реляция очень часто дорого.
Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
ну и да. Так, PGSQL хорошо. Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL. И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
> И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Это очень смелое заявление, несколько отличающееся от действительности.
Это очень смелое заявление, несколько отличающееся от действительности.
AG
Yaroslav Schekin
> Словоблудие.
No you. Если Вы этого не понимаете — пишите всё в машинном коде, не стесняйтесь.
И да, было бы хорошо, если бы Вы не "отмахивались", а писали по существу.
> Паттерн. ООП - это то же ФП по сути.
Хмм... вот это бред так бред, извините. ;) Почитали бы Вы определения того и другого, что ли...
> Объект - есть так же функция высшего порядка.
Ссылку дайте вот на это вот.
> Всё, что можно сделать в ООП, может быть написано в ФП.
"Потрясающе". Вы бы прочитали, что я Вам писал выше, что ли.
> Со слов А. Кея - при создании ООП и Smalltalk он брал за основу модель акторов, а они всё же ФП в первую очередь.
Не нужно приплетать сюда Алана — то, что он имел в виду, и то, что сейчас обычно называют ООП, имеют очень мало общего (не верите — сходите почитайте его объяснения / ответы на вопросы вроде "что Алан Кей имел в виду (vs "современное ООП")?").
> В коде бизнес-логики не должно быть слоя данных ведь
Кто Вам это сказал?
> Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более.
Может, это популярность NoSQL говорит о низкой квалификации большей части "специалистов" в моделировании данных вообще и в реляционной модели в частности? ;)
> Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё.
Потому что "фанатики" с нетерпением ждут, когда же им покажут хоть одну другую математическую модель данных, и подозревают, что NoSQL — это "cнова здорово" набор ad-hoc практик, которые с омерзением выкинули с появлением реляционных СУБД те, кому приходилось тогда есть этот кактус. ;)
> что реляция очень часто дорого.
Реляция — это всего лишь модель данных, Вы это понимаете? Она не может быть "дорогой" в принципе.
> Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
А что я пойму-то? Что выбравшие ElasticSearch не умеют пользоваться PostgreSQL? ;)
Или то, что возможностей PostgreSQL не хватает для каких-то конкретных видов поиска?
> Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL.
Причём тут какие-то "большие компании"? Вы всерьёз считаете вот это вот аргументом... для обоснования хоть чего-то?!
> И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Хмм... о чём, вообще, речь?!
No you. Если Вы этого не понимаете — пишите всё в машинном коде, не стесняйтесь.
И да, было бы хорошо, если бы Вы не "отмахивались", а писали по существу.
> Паттерн. ООП - это то же ФП по сути.
Хмм... вот это бред так бред, извините. ;) Почитали бы Вы определения того и другого, что ли...
> Объект - есть так же функция высшего порядка.
Ссылку дайте вот на это вот.
> Всё, что можно сделать в ООП, может быть написано в ФП.
"Потрясающе". Вы бы прочитали, что я Вам писал выше, что ли.
> Со слов А. Кея - при создании ООП и Smalltalk он брал за основу модель акторов, а они всё же ФП в первую очередь.
Не нужно приплетать сюда Алана — то, что он имел в виду, и то, что сейчас обычно называют ООП, имеют очень мало общего (не верите — сходите почитайте его объяснения / ответы на вопросы вроде "что Алан Кей имел в виду (vs "современное ООП")?").
> В коде бизнес-логики не должно быть слоя данных ведь
Кто Вам это сказал?
> Популярность PGSQL лишь говорит о низкой квалификации большей части специалистов в NoSQL, не более.
Может, это популярность NoSQL говорит о низкой квалификации большей части "специалистов" в моделировании данных вообще и в реляционной модели в частности? ;)
> Самое интересное - фанатики "реляции" пытаются часто есть кактус и всё тащат в неё.
Потому что "фанатики" с нетерпением ждут, когда же им покажут хоть одну другую математическую модель данных, и подозревают, что NoSQL — это "cнова здорово" набор ad-hoc практик, которые с омерзением выкинули с появлением реляционных СУБД те, кому приходилось тогда есть этот кактус. ;)
> что реляция очень часто дорого.
Реляция — это всего лишь модель данных, Вы это понимаете? Она не может быть "дорогой" в принципе.
> Ну из примеров - сделайте полнотекстовый поиск по N полям в PGSQL на товаров более 1 млн в нескольких таблицах. И поймёте почему многие выбирают ElasticSearch тот же.
А что я пойму-то? Что выбравшие ElasticSearch не умеют пользоваться PostgreSQL? ;)
Или то, что возможностей PostgreSQL не хватает для каких-то конкретных видов поиска?
> Но почему-то такие компании как Google продолжают держать хранение многого на MongoDB, а не пихают всё подряд в PGSQL.
Причём тут какие-то "большие компании"? Вы всерьёз считаете вот это вот аргументом... для обоснования хоть чего-то?!
> И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Хмм... о чём, вообще, речь?!
> Хмм... о чём, вообще, речь?!
Наверное о том, что в энтерпрайзе в качестве nosql юзается oracle и mssql :)
А в кровавом энтерпрайзе из каждого угла торчит sap
Наверное о том, что в энтерпрайзе в качестве nosql юзается oracle и mssql :)
А в кровавом энтерпрайзе из каждого угла торчит sap
AG
> И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Это очень смелое заявление, несколько отличающееся от действительности.
Это очень смелое заявление, несколько отличающееся от действительности.
просто любители nosql считают schemaless прям поразительным преимуществом, и что знание птичьего языка запросов у каждого продукта это круто, а sql пережиток прошлого
SB
возвращается две даты, аййдишник и имя. остальные данные полностью отсекаются. 128 ,байт.
типы полей - инт, две даты, и строковые остальные. есть еще пару инт
типы полей - инт, две даты, и строковые остальные. есть еще пару инт
может строковые жирные слишком, ну это конечно просто предположение
IK
может строковые жирные слишком, ну это конечно просто предположение
пока не знаю. пфтаюсь найти какое нибудь ограничение
2_
Владимир Яворский
nosql наверное скоро будет не таким уж nosql ))
я как то couchdb палкой тыкал, а там огрызанный sql, не такой уж он nosql. :)
YS
просто любители nosql считают schemaless прям поразительным преимуществом, и что знание птичьего языка запросов у каждого продукта это круто, а sql пережиток прошлого
А развиваются-то как!
"No to Sql" → "Not only SQL" → "No, SQL!". ;)
"No to Sql" → "Not only SQL" → "No, SQL!". ;)
AG
Yaroslav Schekin
А развиваются-то как!
"No to Sql" → "Not only SQL" → "No, SQL!". ;)
"No to Sql" → "Not only SQL" → "No, SQL!". ;)
именно, вся распределенная аналитика так же шла, в итоге снова пришли к sql
D
> И большие же компании позволили благодаря вливаниям по фичастости MongoDB уже перегнать PGSQL и стать стандартом в энтерпрайзе для NoSQL.
Это очень смелое заявление, несколько отличающееся от действительности.
Это очень смелое заявление, несколько отличающееся от действительности.
По опыту использования это объективная реальность, отделенная от pgsql евангелизма
2_
По опыту использования это объективная реальность, отделенная от pgsql евангелизма
так вы слона не продадите. :)
D
2flower _
так вы слона не продадите. :)
Я бы его если честно закопал и направил сообщество на развитие 1 продукта)
AG
Я бы его если честно закопал и направил сообщество на развитие 1 продукта)
mariadb, она от pg что-то отстаёт, надо развивать
D
просто любители nosql считают schemaless прям поразительным преимуществом, и что знание птичьего языка запросов у каждого продукта это круто, а sql пережиток прошлого
Поменяйте на наличие таблиц и птичьего языка для запросов)
D
mariadb, она от pg что-то отстаёт, надо развивать
Согласен
IT
Я бы его если честно закопал и направил сообщество на развитие 1 продукта)
AG
Поменяйте на наличие таблиц и птичьего языка для запросов)
зачем? там всё стандартизированно и продукты разных компаний и сообществ более-менее этому стандарту следуют