Я изначально предполагал, что все характеристику будут текстовые, числовые (иногда тоже можно в виде текста представить). Ну а далее вставлеете insert into table h_c ('расса', 'афроамериканец'), ('длинный', '1'), ('съел апельсинов', '10'), ('вес', '55.123'), ('массив', 'element1'), ('массив', 'element2'). В примере типы: строка, булево значение, число, не целое число, массив. UPDATE. Вероятно придётся колонку с типом ещё добавить.

Ну а дальше? Как это с конкретным человеком связано?

Ну а дальше? Как это с конкретным человеком связано?

Ну добавьте колонку person_id

Где вы там видите массив?

А, прошу прощения. Проблема с этим решением в том, что работать с этими таблицами свойств банально не удобно. Поэтому и пришли к Hstore/JSON.

индексируются конечно

Каким образом?

Есть набор операций для работы с этими данными. Эти данные индексируются. Эти данные легко десериализуются и т.д.

> Не мусор, а динамически описываемые объекты. Не вижу разницы, из Вашего описания. > Есть набор операций для работы с этими данными И что из того, что он есть? Есть набор операций для работы с BLOB-ами, например (только другой).

Каким образом?

gin индексы

ага, gin

Каким образом?

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

Ну добавьте колонку person_id

Лучше покажите модель. CREATE TABLE там и т.п. Это же немного, по идее...

Лучше покажите модель. CREATE TABLE там и т.п. Это же немного, по идее...

Зачем? Если вы пытаетесь подловить меня на том, о чём я не подумал, ну ок, тогда пишите сразу, что я там упустил. create table X ( person_id int references person(id), name text, value text, type enum )

gin индексы

Да, но очень уж ограничен набор операторов.

> Не мусор, а динамически описываемые объекты. Не вижу разницы, из Вашего описания. > Есть набор операций для работы с этими данными И что из того, что он есть? Есть набор операций для работы с BLOB-ами, например (только другой).

То, что набор операций делает работу с данными типа удобным.

а какого вам не хватает?

Зачем? Если вы пытаетесь подловить меня на том, о чём я не подумал, ну ок, тогда пишите сразу, что я там упустил. create table X ( person_id int references person(id), name text, value text, type enum )

Нет, просто есть несколько таких, которые можно спутать по краткому описанию (а они совсем разные). Так это EAV, что ли?

Нет, просто есть несколько таких, которые можно спутать по краткому описанию (а они совсем разные). Так это EAV, что ли?

Окей, тогда напишите хотя бы 2

Нет, просто есть несколько таких, которые можно спутать по краткому описанию (а они совсем разные). Так это EAV, что ли?

Не знаю

а какого вам не хватает?

Например, отобрать объекты, у которых свойство "возраст" > 35. Как тут будут участвовать GIN на массив?

Окей, тогда напишите хотя бы 2

EAV против 6NF. Легко спутать по краткому описанию, IMHO.

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

Да ладно ? Покажите как с массивами провернуть вышеуказанный финт, чтобы задействовать индексы?

Да ладно ? Покажите как с массивами провернуть вышеуказанный финт, чтобы задействовать индексы?

Какой именно "финт"? Как Вы это в массиве собираетесь хранить, вообще? ;)

Какой именно "финт"? Как Вы это в массиве собираетесь хранить, вообще? ;)

В массиве можно хранить что угодно, вообще, в виде пар ключ/значение.

В массиве можно хранить что угодно, вообще, в виде пар ключ/значение.

не, это все же очень плохая идея

Ключами будут значения по индексам 1, 3, ..., значениями - 2, 4, ....

не, это все же очень плохая идея

Вы не поняли ? Я про это и говорю. Поэтому и говорю про то, что лучше JSON, потому что он индексируется как положено.

Но вообще, если есть массивы, то можно хранить всё.

Ключами будут значения по индексам 1, 3, ..., значениями - 2, 4, ....

Эээ... я даже и не знаю, что на это ответить. :( В bytea тоже можно хранить всё что угодно... и что?

Но вообще, если есть массивы, то можно хранить всё.

Нет, можно делать вид, что Вы храните всё, что угодно. Ну или, фактически, написать свою СУБД внутри существующей... "почему бы нет?"

Эээ... я даже и не знаю, что на это ответить. :( В bytea тоже можно хранить всё что угодно... и что?

Вообще-то это стандартный приём. Например, в Лиспе это называется ассоциативный список - '((first-name . "Yaroslav") (last-name . "Schekin")).

Вообще-то это стандартный приём. Например, в Лиспе это называется ассоциативный список - '((first-name . "Yaroslav") (last-name . "Schekin")).

Может быть, не стоит путать массивы со списками? И причём тут вообще LISP?

Может быть, не стоит путать массивы со списками? И причём тут вообще LISP?

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

Можно объяснить, чем в плане nosql 11 отличается от 10?

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

> В массивах можно делать то же самое, если структура одноуровневая Это уже из серии "настоящий программист может писать на ассемблере... в любом языке программирования!" ;) Можно любые данные в numeric хранить (пока влезают), закодировав их соответсвующим образом... и это примерно так же "нормально", как хранить ключ/значение в текстовых массивах. :(

Ладно, коллеги, меня ждут великие дела. До встречи, всем отличного дня! ?

Нет, просто есть несколько таких, которые можно спутать по краткому описанию (а они совсем разные). Так это EAV, что ли?

Видимо EAV

EAV против 6NF. Легко спутать по краткому описанию, IMHO.

Т.е. она не в 6нф? Думаю, что там.

Видимо EAV

Ну так это anitpattern в RDBMS. Обоснования легко находятся в интернете.

Т.е. она не в 6нф? Думаю, что там.

Конечно, нет. EAV вообще не реляционна (она просто с виду похожа, да).

Конечно, нет. EAV вообще не реляционна (она просто с виду похожа, да).

Что значит не реляционна? не представима в реляционной бд? ну вот же, предтавил.

Например, отобрать объекты, у которых свойство "возраст" > 35. Как тут будут участвовать GIN на массив?

Возраст совать в JSON?! Более чем "хороший" пример использования JSON-ов и тому подобного.

Конечно, нет. EAV вообще не реляционна (она просто с виду похожа, да).

Блин, ну бессмысленно это обсуждать, пока не сойдёмся на понятии "не реляционна".

Что значит не реляционна? не представима в реляционной бд? ну вот же, предтавил.

Да, не предствима. SQL database <> relational database. (В SQL могут быть, например, таблицы без уникальных ключей... которые не являются отношениями.) > ну вот же, предтавил. Не представили. Укажите домен "value".

text?)

Я как капитан

Вы хотите сказать, что в случае чисел нет никаких гаранитий, что там числа?

всем времени, подскажите кто сталкитвался с ошибкой подклчения org.postgresql.util.PSQLException: Could not find a server with specified targetServerType: master

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

text?)

Вы понимаете, что такое домен? Это примерно то же самое, что и тип данных. Т.е. он должен определять все существенные свойства — множество допустимых значений, их интерпретацию, допустимые операторы и их результаты... А для: create table X (person_id int references person(id), name text, value text, type enum) Я могу легко вставить: 1, 'current_temperature_celsius', 'green', 'что-нибудь'; или 2, 'current_temperature_celsius', '-400', 'что-нибудь';

Да, потому что множество допустимых знаечений будет зависеть от поля type. Видимо constraint-ы нужны в виде check

в postgresql только i := i + 1 ?? есть ++i, i++, i += 1 ?

Да, потому что множество допустимых знаечений будет зависеть от поля type. Видимо constraint-ы нужны в виде check

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

Да, потому что множество допустимых знаечений будет зависеть от поля type. Видимо constraint-ы нужны в виде check

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

Вообщем, я всего лишь хотел сказать, что это всё дело в 6нф

в postgresql только i := i + 1 ?? есть ++i, i++, i += 1 ?

В PostgreSQL SQL такого вообще нет. Вы из MS SQL к нам пришли, я правильно помню?

Хотя отсуствие реляционной модели в ё первоначальном смысле будет вас кидать сейчас на тонну сообщений мне в ответ

В PostgreSQL SQL такого вообще нет. Вы из MS SQL к нам пришли, я правильно помню?

+

Вообщем, я всего лишь хотел сказать, что это всё дело в 6нф

А 6NF — это совсем другая, реляционная модель.

+

Тогда Вас подводят Ваши привычки. ;) Дело в том, что в PostgreSQL есть много языков хранимых функций, и они — совсем не SQL. Т.е. "напрямую" их использовать в SQL нельзя! (Вы сейчас пишете про plpgsql.) Т.е. SQL и plpgsql — это разные языки, просто с виду довольно похожи. ;)

Ребят, кто-нибудь FDW for Hadoop тестил?

как оно? :)

А 6NF — это совсем другая, реляционная модель.

это уже перенормализация

Тогда Вас подводят Ваши привычки. ;) Дело в том, что в PostgreSQL есть много языков хранимых функций, и они — совсем не SQL. Т.е. "напрямую" их использовать в SQL нельзя! (Вы сейчас пишете про plpgsql.) Т.е. SQL и plpgsql — это разные языки, просто с виду довольно похожи. ;)

обязательно избавлюсь от привычек, дело времени ;) з.ы. спасибо з.ы. в mssql тоже не sql, а t-sql

это уже перенормализация

Такого не бывает. ;)

обязательно избавлюсь от привычек, дело времени ;) з.ы. спасибо з.ы. в mssql тоже не sql, а t-sql

НЕТ! Вот в этом-то и дело: в MS SQL только t-sql, понимаете? Т.е. клиент может прямо "говорить" с сервером на t-sql, а в PostgreSQL такое (напрямую) невозможно, т.е. клиент не может "говорить" с сервером на pl/python, например. И здесь pl/pgsql ничем не лучше pl/python в этом отношении.

НЕТ! Вот в этом-то и дело: в MS SQL только t-sql, понимаете? Т.е. клиент может прямо "говорить" с сервером на t-sql, а в PostgreSQL такое (напрямую) невозможно, т.е. клиент не может "говорить" с сервером на pl/python, например. И здесь pl/pgsql ничем не лучше pl/python в этом отношении.

спасибо за пояснение ^^ всё же есть ли в plpgsql сахарок на инкремент ?)

спасибо за пояснение ^^ всё же есть ли в plpgsql сахарок на инкремент ?)

Нет такого.

Нет такого.

??

НЕТ! Вот в этом-то и дело: в MS SQL только t-sql, понимаете? Т.е. клиент может прямо "говорить" с сервером на t-sql, а в PostgreSQL такое (напрямую) невозможно, т.е. клиент не может "говорить" с сервером на pl/python, например. И здесь pl/pgsql ничем не лучше pl/python в этом отношении.

Вчера в сиквеле воспользовался IIF. Говорят это из шарпа...

А еще так долго ждал format и дождался

Вчера в сиквеле воспользовался IIF. Говорят это из шарпа...

А кто его помнит... это с 2012, кажется. Кстати, кто Вам мешает создать в своей базе PostgreSQL эту функцию? Это же всего лишь простой "сахар".

Да я ж не спорю особо. Хотел просто сказать что не транзакт-сиквелом единым )

Самая вредная привычка от сиквела это переменные

Самая вредная привычка от сиквела это переменные

Пишите на PL/что-нибудь. ;) Хотя да, нормальные переменные сессии (или хоть "глобальные" временные таблицы) были бы иногда очень кстати.

а кто-нибудь знает, как pg именя для индексов формирует

может етсь какая функция в каталоге?

Вчера в сиквеле воспользовался IIF. Говорят это из шарпа...

перегруженный case ^^

а кто-нибудь знает, как pg именя для индексов формирует

логику выбора имени для индекса можно подсмотреть в исходниках - функция ChooseIndexName в src/backend/commands/indexcmds.c

может етсь какая функция в каталоге?

нет, имя подбирается по определённым правилам

всем привет. такой вопрос. у меня есть массив строк ['apple', 'banana', 'orange']. мне надо делать query так, чтобы он дал все данные где fruits это либо apple, либо banana, либо orange. (то есть по содержанию массива) примерно так Id | fruits 1 blueberry 2 apple 3 banana 4 orange длину массива и элементы в нем я не знаю

есть какой-то онлайн сервер бесплатный для постгреса?

чтоб там бд создать, и работать с ней удалённо

aws free tier, gcp always free

всем привет. такой вопрос. у меня есть массив строк ['apple', 'banana', 'orange']. мне надо делать query так, чтобы он дал все данные где fruits это либо apple, либо banana, либо orange. (то есть по содержанию массива) примерно так Id | fruits 1 blueberry 2 apple 3 banana 4 orange длину массива и элементы в нем я не знаю

Это хоть нужно? WITH t(id, fruit) AS ( VALUES (1, 'apple'), (2, 'orange'), (3, 'blueberry') ) SELECT * FROM t WHERE fruit = ANY(ARRAY['apple', 'banana', 'orange'])

всем привет. такой вопрос. у меня есть массив строк ['apple', 'banana', 'orange']. мне надо делать query так, чтобы он дал все данные где fruits это либо apple, либо banana, либо orange. (то есть по содержанию массива) примерно так Id | fruits 1 blueberry 2 apple 3 banana 4 orange длину массива и элементы в нем я не знаю

select * from fruitsTable where fruits in ('apple', 'banana', 'orange')

select * from fruitsTable where fruits in ('apple', 'banana', 'orange')

массив динамичный, я НЕ знаю про содержание

с другого сервера приходит массив строк, и надо как то по этим делать запрос

Доброго дня всем! Приглашаем на работу в Москве Разработчиков баз данных: Мы СтандартПроект (www.stdpr.ru) Мы существуем как коллектив уже более 20 лет и являемся лидером в области разработки и внедрения высокоинтеллектуальных информационных систем, которые в основном имеют федеральное значение, в связи с чем наши основные заказчики-это государственные органы страны. Сейчас мы развиваем лабораторию digital продуктов и собираем команду из увлеченных и амбициозных специалистов, в том числе разработчиков, которым интересно принять участие в разработке больших распределённых систем обработки информации (более 1 млрд новых записей каждый месяц). Что понадобится в работе: * знание SQL * знание СУБД Oracle и PostgreSQL, опыт разработки в них (соответственно знание PL/SQL и pgPL/SQL) * желание изучать новые технологии, решать сложные и нетривиальные задачи Приветствуется знание: * PL/Proxy * Perl * Londiste * pgq * xml * json * pgBouncer Что предлагаем: - Полностью официальное трудоустройство с так же полностью "белой" зарплатой (примерная вилка 120 000 -180 000 на руки) - Гибкий график работы (работа на результат в команде) - Необычный уютный офис в стиле лофт в центе Москвы (между Менделеевской, Новослободской и Достоевской. Пешком 10 минут максимум от Достоевской) - Небольшой и дружный коллектив профессионалов, преданных своему делу, готовых делиться знаниями ? - Только лучшая современная техника и только лицензионный софт (любой, который потребуется на работе) - Возможность профессионального обучения и сертификации за счёт компании - Демократичное руководство - минимум формальностей на работе Ждём Ваши резюме или контакты или вопросы с нетерпением! lagutkina@stdpr.ru или в личку

существует ли компания, которая не является лидером ???

наверняка) но мы лидер без сомнений))

существует ли компания у которого hr не девушка ?

Yaroslav, @dmitigr подумал ещё немного и решил, что похоже всё-таки удобней признаки в jsonb хранить и работать с ними. Вообщем, спасибо запримеры.

aws free tier, gcp always free

ty

существует ли компания у которого hr не девушка ?

Я знаю 100% что в mail.ru не девушка.