Это Вы просто тестовые значения заполняете, что ли?

нет

вы точно хотите бизнес-логику в базу положить?

что бы одним селектом получать слоты

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

вы точно хотите бизнес-логику в базу положить?

это не бизнеслогика, это ток инициализаия таблиц

и записей

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

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

один селект и обращение к куче таблиц, общим списком вывод

это не бизнеслогика, это ток инициализаия таблиц

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

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

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

и не может быть варианта что они будут не нужны

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

Не для реляционной СУБД. И это ещё не считая многих связанных с ним технических ограничений PostgreSQL.

Не для реляционной СУБД. И это ещё не считая многих связанных с ним технических ограничений PostgreSQL.

а мне и не надо как реляционная всюду

тут мне надо как noSQL

и не может быть варианта что они будут не нужны

это никак не противоречит и не относится к вышесказанному

а мне и не надо как реляционная всюду

А зачем Вы тогда микроскопом (PostgreSQL) гвозди забиваете? Так и возьмите какую-нибудь NoSQL базу, если она Вам и нужна...

это все пркиольно, но

ERROR: invalid input syntax for type bytea LINE 1: INSERT INTO quest_slot_008 (idc, data) VALUES (1,E'\\008'::b... ^ QUERY: INSERT INTO quest_slot_008 (idc, data) VALUES (1,E'\\008'::bytea) CONTEXT: PL/pgSQL function inline_code_block line 24 at EXECUTE SQL state: 22P02

почему именно 008

А зачем Вы тогда микроскопом (PostgreSQL) гвозди забиваете? Так и возьмите какую-нибудь NoSQL базу, если она Вам и нужна...

сейчас не до этого, проще так забахать

почему именно 008

У Вас вообще плохой стиль написания кода на plpgsql. Но перепечатывать его с картинки ради примеров как-то не тянет...

У Вас вообще плохой стиль написания кода на plpgsql. Но перепечатывать его с картинки ради примеров как-то не тянет...

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

У Вас вообще плохой стиль написания кода на plpgsql. Но перепечатывать его с картинки ради примеров как-то не тянет...

https://pastebin.com/tH3Hw4kE

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

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

блин, почему именно 8, не 7, не 9, не 5

с клиентского

догонять до текущего индекса?

догонять до текущего индекса?

да, есть персонажи

добавляю таблицу

для каждого перса нужна запись в новой таблице

для каждого перса нужна запись в новой таблице

Make me unsee it. :( Знаете, у меня такое впечатление, как если бы Вы пытались быстро написать финансовое приложение, положив в его основу, например, то, что 2*2=5, потому что "нет времени". Конец немного предсказуем, мне кажется.

селект делается быстро, одним запросом, что еще надо?

при наследовании

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

что тут плохого

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

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

при наследовании

Давайте-давайте. Удачи с наследованием. Главное, не слушайте никого — что там их всякая теория, или опыт, или документация — фигня всё это, когда надо "быстро написать", верно?

да, типа того

ERROR: invalid input syntax for type bytea LINE 1: INSERT INTO quest_slot_008 (idc, data) VALUES (1,E'\\008'::b... ^ QUERY: INSERT INTO quest_slot_008 (idc, data) VALUES (1,E'\\008'::bytea) CONTEXT: PL/pgSQL function inline_code_block line 24 at EXECUTE SQL state: 22P02

лучше скажите кто думает чего именно на 008 такое

хехе кажется кто-то обижается что кто-то не следует некоторым канонам

такс, я выснил что может только семерка быть в SELECT E'\\327'::bytea; таком запросе

8ки не может быть

« вводимое значение оно преобразуется в трёхциферное восьмеричное значение» ясно, кажется разобрался) спс

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

В доке по postgresql есть туториал (я так понимаю, что это вводный раздел для новичков) и там про наследование расказывается. https://www.postgresql.org/docs/11/static/tutorial-inheritance.html Вопросы: 1. Зачем в доке в туториале про это рассказывается? чтобы не пользоваться этим никогда? ? 2. Какие есть hacks с наследованием?

тоже давно читал всю доку постгреса, оттуда и узнал про наследование, погуглил крутая вещь, хз чего так челики его боятся, хорошая фича

В доке по postgresql есть туториал (я так понимаю, что это вводный раздел для новичков) и там про наследование расказывается. https://www.postgresql.org/docs/11/static/tutorial-inheritance.html Вопросы: 1. Зачем в доке в туториале про это рассказывается? чтобы не пользоваться этим никогда? ? 2. Какие есть hacks с наследованием?

> 1. Зачем в доке в туториале про это рассказывается? чтобы не пользоваться этим никогда? Я её не писал. В документации вообще немало, эээ... сомнительного рассказывается и показывается.

> 1. Зачем в доке в туториале про это рассказывается? чтобы не пользоваться этим никогда? Я её не писал. В документации вообще немало, эээ... сомнительного рассказывается и показывается.

Там пример с городами и столицами. Вы бы так не стали делать?)

В доке по postgresql есть туториал (я так понимаю, что это вводный раздел для новичков) и там про наследование расказывается. https://www.postgresql.org/docs/11/static/tutorial-inheritance.html Вопросы: 1. Зачем в доке в туториале про это рассказывается? чтобы не пользоваться этим никогда? ? 2. Какие есть hacks с наследованием?

> 2. Какие есть hacks с наследованием? Такие, например: https://www.keithf4.com/removing-old-data/

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

Там пример с городами и столицами. Вы бы так не стали делать?)

Конечно, не стал бы. И даже в конце tutorial есть предупреждение, а уж по ссылкам их куда больше.

но у меня другой случа, конечно

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

Это партицирование по датам (к примеру помесячно)

Это партицирование по датам (к примеру помесячно)

ну да, не силен в терминах

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

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

Для этого можно просто пользоваться индексами. Т.к. обычно старые данные всё равно нужны, только реже. И про партиционирование я писал, кстати.

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

В новых версиях postrgesql это сделано без наследования

колонка одним альтом добавляется в таком случае

В новых версиях postrgesql это сделано без наследования

ясн, ну хз)

Давайте-давайте. Удачи с наследованием. Главное, не слушайте никого — что там их всякая теория, или опыт, или документация — фигня всё это, когда надо "быстро написать", верно?

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

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

можно огурчиком стать

просто я понял, что вы против, но не очень понял, почему:( какие подводные камни?

Although inheritance is frequently useful, it has not been integrated with unique constraints or foreign keys, which limits its usefulness. See Section 5.9 for more detail.

Ярослав выше про это сказал

мне как раз и круто что ключи одинаковые могут быть

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

Технические: https://www.postgresql.org/docs/current/static/ddl-inherit.html#DDL-INHERIT-CAVEATS (и походите по ссылкам) Теоретические: в реляционной теории более-менне аналогичные цели достигаются другими средствами. Поэтому одно с другим вообще плохо скрещивается.

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

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

Для моделирования? Конечно, нет.

я думаю что они не могут объяснить нормально, потмоу что не сталкивались с проблемами, и не пробовали «не верный» путь, могу предположить что евангелисты или кто там кто придумал говорить что это не верный путь сталкивался с проблемой, что когда ты наследуешься от таблицы в начале, при разработке свежинькой базы — ты видишь текущую картину, но потом может понадобиться расшрять базовую, но это расширение не всюду надо, а по скольку с базами это не отрефакторишь легко как с кодом, то предпочитают вообще не использовать

я думаю что они не могут объяснить нормально, потмоу что не сталкивались с проблемами, и не пробовали «не верный» путь, могу предположить что евангелисты или кто там кто придумал говорить что это не верный путь сталкивался с проблемой, что когда ты наследуешься от таблицы в начале, при разработке свежинькой базы — ты видишь текущую картину, но потом может понадобиться расшрять базовую, но это расширение не всюду надо, а по скольку с базами это не отрефакторишь легко как с кодом, то предпочитают вообще не использовать

Ну-ну. Может, объясните мне нормально, почему бы не использовать при расчётах тождество "2+2=5"? (Может, Вам или мне нужно попробовать «не верный» путь? А иначе: "кто там кто придумал говорить что это не верный путь".)

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

Ну-ну. Может, объясните мне нормально, почему бы не использовать при расчётах тождество "2+2=5"? (Может, Вам или мне нужно попробовать «не верный» путь? А иначе: "кто там кто придумал говорить что это не верный путь".)

то есть по каким-то причинам очевидно что использование наследование на столько же не верно как 2+2 = 5?

Тут даже не наследование, а партиционирование, если быть точным

Само наследование, как таковое, ни разу не видел нигде чтоб применялось

Само наследование, как таковое, ни разу не видел нигде чтоб применялось

ну вот у меня применяется, получаю 60 записей, по одному селекту по айди

то есть по каким-то причинам очевидно что использование наследование на столько же не верно как 2+2 = 5?

А разве я уже об этом не писал? Вы где-то в реляционной теории наследование такого вида видели?

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

А разве я уже об этом не писал? Вы где-то в реляционной теории наследование такого вида видели?

я там json-полей с инндексами тоже не видел

А разве я уже об этом не писал? Вы где-то в реляционной теории наследование такого вида видели?

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

Угу, вопрос ещё глубже, зачем вообще 10 таблиц?

я там json-полей с инндексами тоже не видел

А что бы им там делать? Первое — yet another domain, второе — вообще понятие уровня физической реализации.

нету в подходе каком-то там чего-то там, ну вот я новый подход изобрел, норм подход

я евангилист, ставьте лайк что бы я написал книжку

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

пока что твои аргументы именно так и выглядят, «такого нет в теории»

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

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

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

Это не так работает. Ты или берёшь инструмент и следуешь налагаемым его теоретической основой ограничениям или костылишь.

Это не так работает. Ты или берёшь инструмент и следуешь налагаемым его теоретической основой ограничениям или костылишь.

Агент Печенька, со всем уважением, я к вам прислушаюсь, мне нравится ваш ник

Ко мне не прислушивайся, а вот теорию изучи.

Ко мне не прислушивайся, а вот теорию изучи.

да она мне не надо)

пока что твои аргументы именно так и выглядят, «такого нет в теории»

2+2=5 тоже нет в теории алгебры. Я бы в самом деле хотел послушать связное обоснование (а не "да это же бред!") почему этим нельзя пользоваться. Или прекратите требовать того же от тех, кто хоть как-то разбирается в реляционной теории, ok?

да она мне не надо)

Огромное заблуждение.

2+2=5 тоже нет в теории алгебры. Я бы в самом деле хотел послушать связное обоснование (а не "да это же бред!") почему этим нельзя пользоваться. Или прекратите требовать того же от тех, кто хоть как-то разбирается в реляционной теории, ok?

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

пора вызывать полицию SQL

ладн, сорри) всем спасибо за общение, но надо еще много чего сделать

Для начала советую почитать зачем реляционные бд вообще нужны.

Для начала советую почитать зачем реляционные бд вообще нужны.

да мне пофигу, у меня есть потребности, мне их сейчас надо закрыть, вот сейчас, не еще месяц, а вот сейчас

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

Нет, не звучит. Просто требование обосновать неприменение наследования в RDBMS примерно также "нормально", как требование обосновать неприменение 2+2=5 в алгебре. Мне почему-то трудно это обосновывать. Может, кто-нибудь другой попробует...

да мне пофигу, у меня есть потребности, мне их сейчас надо закрыть, вот сейчас, не еще месяц, а вот сейчас

Мне тоже, ты творишь хуйню оправдывая её срочностью.

ну полюбому я делаю что-то не так