
Dmitriy
19.06.2018
05:15:04
Пивоты - это баги в проектировании бд, и это неправильно

Саша
19.06.2018
05:17:32

Dmitriy
19.06.2018
05:18:08
Почитайте про нормализацию

Саша
19.06.2018
05:18:55

Google

Dmitriy
19.06.2018
05:19:17
Хотя вложенных таблиц и остального я много повидал

Саша
19.06.2018
05:20:52

Dmitriy
19.06.2018
05:21:00
Почитайте про уровни нормализации. В википедии точно есть

Саша
19.06.2018
05:22:00

Dmitriy
19.06.2018
05:22:10
Их 6, а по сути 7
Может и троллинг, а может вы в базах просто в нуль
Когда нужна третья таблица, это баг и плохо

Илья
19.06.2018
05:30:07

Dmitriy
19.06.2018
05:31:47
Они у вас в разных таблицах?
Ну если так, то тоже читаем про нормализацию

Илья
19.06.2018
05:32:35

Dmitriy
19.06.2018
05:33:19
В нормальной дизайна бд, третья таблица не нужна.
Но бывает, что делал базу рукожоп, для этого и нужны эти костыли

Google

Dmitriy
19.06.2018
05:36:41
Если проект на ранней стадии, то лучше привести базу в порядок, что бы потом не прыгать через таблицы. Для локалхоста ещё подойдёт, а на больших базах, да и на любимом посгрессе производительность уйдёт просто в Гулина
В нулину
В 0
Четко же написано, что не нужны в базе лишние сущности. Третья таблица- это лишняя сущность

Nik
19.06.2018
05:43:16
а то тут пол чата сейчас себя дураками почувствовало

Dmitriy
19.06.2018
05:43:47
Нормальные формы бд
В гугле

Nik
19.06.2018
05:43:55

Dmitriy
19.06.2018
05:44:13
Вики

Nik
19.06.2018
05:45:01
ты совсем глупый? ссылочку дай, удели 2 минуты времени

Илья
19.06.2018
05:45:05
без 3 таблицы в м:м нарушается 1нф
можешь опровергнуть ссылкой

Nik
19.06.2018
05:45:27
не может, в том и дело

Dmitriy
19.06.2018
05:45:56
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

Илья
19.06.2018
05:47:45

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

Google

Nik
19.06.2018
05:48:20

Dmitriy
19.06.2018
05:48:24
А Вы очень быстро читаете
Речь идет о СУРБД

Nik
19.06.2018
05:49:20

Dmitriy
19.06.2018
05:49:32
А то щас еще в монго скатимся

Nik
19.06.2018
05:50:04
зачем? вопрос конкретно про пивоты в рсубд

Илья
19.06.2018
05:50:05

Dmitriy
19.06.2018
05:50:12
А прочитать это сложно ?
Извините, Я не могу так. Ну сходиде на хекслет, там курс вмемянемый есть.

Nik
19.06.2018
05:51:46
хех) ясно-понятно)

Dmitriy
19.06.2018
05:51:50
Базы данных: SQL (DDL/DML)
https://ru.hexlet.io/courses
В общем если лень читать, то все очень просто. В базе ничего не должно повторяться, и не должно быть ничего лишнего. Вот как это сделать - это уже другой вопрос, и зачастую довольно сложный.

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

Илья
19.06.2018
05:57:29
Давай скажешь как избежать повторения для этого примера без 3 таблицы? Пример ведь элементарный
Есть пользователи и группы (м:м), как тут без 3 таблицы?

Dmitriy
19.06.2018
05:58:00
что за мм

Илья
19.06.2018
05:58:12
Many to many

Timur
19.06.2018
06:00:15
как запустить миграцию на удаленную базу?
?

Google

Dmitriy
19.06.2018
06:00:52
https://stackoverflow.com/questions/35307406/hibernate-many-to-many-without-third-table
Извини за Java

Илья
19.06.2018
06:01:29

Dmitriy
19.06.2018
06:02:56
Hibernate это тот же JPA, или просто ORM

Илья
19.06.2018
06:03:07

Timur
19.06.2018
06:03:10
пишет access denied for user in localhost

Dmitriy
19.06.2018
06:03:19
I have two tables (Users and UserRole)

Timur
19.06.2018
06:03:23

Илья
19.06.2018
06:04:00

Dmitriy
19.06.2018
06:04:21
Ну прочитай же.
У меня при таком, лишних таблиц не создается. Java, SQL Server

Илья
19.06.2018
06:06:44

Dmitriy
19.06.2018
06:07:34
В смысле пользователи и роли ?

Илья
19.06.2018
06:08:33

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

Dmitriy
19.06.2018
06:11:02

Илья
19.06.2018
06:13:28
Теперь давай добавим для каждой роли описание

Dmitriy
19.06.2018
06:14:56
Ты действительно думаешь, что это сложно ?

Илья
19.06.2018
06:15:38

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

Google

Dmitriy
19.06.2018
06:16:29
http://pogugli.com/?323736

Nik
19.06.2018
06:16:57
у тебя тут не м2м если чо

Dmitriy
19.06.2018
06:19:37
У меня там что угодно может быть.

Илья
19.06.2018
06:20:51

Timur
19.06.2018
06:20:59
ролей

Dmitriy
19.06.2018
06:22:32
ой...
что за описания ?

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

Dmitriy
19.06.2018
06:23:19
Я могу сколько угодно ролей назначить

Timur
19.06.2018
06:23:38
Не спорю

Dmitriy
19.06.2018
06:23:47
ну сколько в стрингу влезет

Timur
19.06.2018
06:23:58
То есть?

Dmitriy
19.06.2018
06:24:07
могу даже больше, если сурово извратиться )))

Timur
19.06.2018
06:24:28
Типа:
"admin, editor, manager"?

Dmitriy
19.06.2018
06:24:47
С Filestream буду в поле брать из файла

Timur
19.06.2018
06:24:50
Вот такое значение в одной записи в users?

Dmitriy
19.06.2018
06:25:43
но это извращение чисто теоретическое