Пивоты - это баги в проектировании бд, и это неправильно

Пивоты - это баги в проектировании бд, и это неправильно

Чойта? реф таблицы это баги в проектировании бд? хахаха

Почитайте про нормализацию

Почитайте про нормализацию

То есть ты не допускаешь в принципе существовании связей many to many в грамотно спроектированной бд?

Хотя вложенных таблиц и остального я много повидал

Хотя вложенных таблиц и остального я много повидал

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

Почитайте про уровни нормализации. В википедии точно есть

Почитайте про уровни нормализации. В википедии точно есть

Почитайте сами про уровни нормализации. А то звучит как толстый троллинг

Их 6, а по сути 7

Может и троллинг, а может вы в базах просто в нуль

Когда нужна третья таблица, это баг и плохо

Когда нужна третья таблица, это баг и плохо

Есть пользователи и группы (м:м), как тут без 3 таблицы?

Они у вас в разных таблицах?

Ну если так, то тоже читаем про нормализацию

Они у вас в разных таблицах?

было бы странно, если были бы в одной

В нормальной дизайна бд, третья таблица не нужна.

Но бывает, что делал базу рукожоп, для этого и нужны эти костыли

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

В нулину

В 0

Четко же написано, что не нужны в базе лишние сущности. Третья таблица- это лишняя сущность

Четко же написано, что не нужны в базе лишние сущности. Третья таблица- это лишняя сущность

давай ссылочку что читать

а то тут пол чата сейчас себя дураками почувствовало

Нормальные формы бд

В гугле

давай ссылочку что читать

^

Вики

ты совсем глупый? ссылочку дай, удели 2 минуты времени

без 3 таблицы в м:м нарушается 1нф

можешь опровергнуть ссылкой

не может, в том и дело

https://ru.wikipedia.org/wiki/%D0%9D%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0

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

https://bourabai.ru/einf/subd1.htm

http://www.mstu.edu.ru/study/materials/zelenkov/toc.html

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

ну эта фраза вроде как не в твою пользу

хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов)

https://bourabai.ru/einf/subd1.htm

про Ingres улыбнуло

А Вы очень быстро читаете

Речь идет о СУРБД

А Вы очень быстро читаете

а я не вижу что конкретно мне читать. ссылку на оглавление и на вики кинуть - это мощно

А то щас еще в монго скатимся

зачем? вопрос конкретно про пивоты в рсубд

хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов)

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

А прочитать это сложно ?

Извините, Я не могу так. Ну сходиде на хекслет, там курс вмемянемый есть.

хех) ясно-понятно)

Базы данных: SQL (DDL/DML)

https://ru.hexlet.io/courses

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

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

Давай скажешь как избежать повторения для этого примера без 3 таблицы? Пример ведь элементарный

Есть пользователи и группы (м:м), как тут без 3 таблицы?

что за мм

Many to many

как запустить миграцию на удаленную базу?

?

https://stackoverflow.com/questions/35307406/hibernate-many-to-many-without-third-table

Извини за Java

как запустить миграцию на удаленную базу?

указать в .env креды удаленной базы, запустить миграции

Hibernate это тот же JPA, или просто ORM

https://stackoverflow.com/questions/35307406/hibernate-many-to-many-without-third-table

где там речь о двух таблицах?

пишет access denied for user in localhost

I have two tables (Users and UserRole)

указать в .env креды удаленной базы, запустить миграции

хотя я прописал ip сервера

I have two tables (Users and UserRole)

есть ещё такой варик: читать на стаковерфлоу не только вопрос, но и ответ

Ну прочитай же.

У меня при таком, лишних таблиц не создается. Java, SQL Server

У меня при таком, лишних таблиц не создается. Java, SQL Server

в таком случае для моего примера выше какие две таблицы ты бы создал?

В смысле пользователи и роли ?

В смысле пользователи и роли ?

да, один пользователь может иметь много ролей и одна роль может соответствовать многим пользователям

Столкнулся с самой большой проблемой при проектировании приложения. Как назвать модель (и таблицу соответственно)? :) Предположим есть Организация. И есть возможность предложить добавить организацию. Как назвать моель для таких предложений/заявок?) Пихать в общую таблицу организаций с другим статусом не вариант в моём случае

Теперь давай добавим для каждой роли описание

Ты действительно думаешь, что это сложно ?

Ты действительно думаешь, что это сложно ?

Нет, это просто, для этого существуют М:М Интересно как ты уместишь это в двух таблицах

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

http://pogugli.com/?323736

есть ещё такой варик: читать на стаковерфлоу не только вопрос, но и ответ

+

у тебя тут не м2м если чо

У меня там что угодно может быть.

У меня там что угодно может быть.

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

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

Он имеет ввиду что должна быть промежуточная связующая таблица с полe id, user_id, role_id таблица. Без нее получится хрень без описания

ролей

ой...

что за описания ?

А в целом это возможно с двумя таблицами. В UserRole будет просто user_id, role (не role_id)

Я могу сколько угодно ролей назначить

Не спорю

ну сколько в стрингу влезет

То есть?

могу даже больше, если сурово извратиться )))

Типа: "admin, editor, manager"?

С Filestream буду в поле брать из файла

Вот такое значение в одной записи в users?

но это извращение чисто теоретическое