Не соответствует третьей нормальной форме, мудак блять.
ясен хуй не соответствует, вообще все хуйня или добавить/убрать несколько таблиц, изменить связи?
Нахуй тебе DateDogovor?
Это я затычку поставил, чтобы спросить как между клиентом и договором не делать многие ко многим
(гений)
В чем проблема сделать многие ко многим?
Ух бля, будто в технарь вернулся на курсач по бд
Так многие ко многим же не соответствует третей нормальной форме? Или я что то путаю?
Дальше плати.
Это обычная связь. Убирай это говно и впиливая многие ко многим. твоя затычка это пиздец нахуй бялть ебаный в рот ебал просто маму
Ох с вкрутую
И еще я нихуя не понял что за otdel_sotrudniki. Это что вообще за месиво?
Сука у меня даже она не во второй форме
>Dogovor
>VidiOplati
Alo yoba eto ty?
А как мне сделать, таблицу в которой блять будут отображаться сотрудники и отделы, которые участвуют в проекте, в пизду нахуй переделывать
Ты ебанутый?
По первому лучше не ебаться а завести поле в табе клиента.
Второе - очевидно напрашивается еще одна сущность.
Есть сотрудник. Есть отдел. Сотрудник может быть только в одном отделе. 1 ко многим. зачем тут громоздить эти громозди.
Может ты?
Ого, ничоси, што гна оп-пике происходит?
Поле "Otdel" в таблице "Sotrydnik" лишнее.
Таблица "DateDogovor" реально лишняя.
Для слежения за самими заказами легче будет ввести таблицу, где будет сущность "многие-ко-многим" с сотрудниками, с датой входа и выхода в промежуточной таблице, а если проект выполняется повторно то можно добавить поле "Повторный" типа bool.
ER диаграмма, гуманитарий ты наш.
Yoby net doma, eto Peka. Chto peredat'?
Спасибо за годные советы. Только не до конца понял как эту промежуточную таблицу сделать. Ща переделаю
Короче тебе надо бы еще одну сущность сделать с заказами\проектами. А не просто договор.
Только еще хуйня в том, что у меня много сотрудников и много отделов, хотя это наверное ничего не меняет
и что?
Чтобы следить точнее за проектами, можно добавить таблицу "Проект", к которому прикрепляется договор, отдел, а между отделом и проектом таблицу "многие-ко-многим", в которой написана дата входа и выхода отдела в проект
Так? Или долбоеб?
>Otdel
>Sotrudniki
ебать я ору с тупых даунов. кто тебя так научил таблицы называть?
И вообще для таблицы VidiOplati таблица Bank нужна?
В договоре зачем айди отдела?
ДА Я ЕБАЛ ВАШИХ CUSTOMERS, EMPLOYEE, DEPARTMENTS и так далее
Сэр, вы ебобо?
Какого чёрта От отдела до задания связь многие ко одному?
Автоматически добавилось
Я бы сделал что-то вроде этого. Нужные поля накидаешь.
Половина на русском, половина на английском.
Внимание вопрос: ты тупой?
Думаю, в компании 1С :)))
>ER диаграмма
На чём сделана опташнах?
Почему договор и видБлятьОплаты и Банк 1 к одному? Типы ключей не совпадают
По одному договору же может быть несколько видов оплат в реале.
Как с чеками - тыщу с безнала и писот вот вам налом
ну а как сделать, чтобы у разных отделов могло быть разделено одно задание
Задачка на нормализацию,
У тебя там связи еще напутаны.
Много сотружников - 1 отдел.
Один отдел - много заданий. Или может ли 2 отдела делать одно задание?
В договоре много лишнего говна.
1 клиент - много договоров, а у тебя наоборот.
Через сотрудников. Учет же будет вестись по ним.
чуваки блять не понимаю вас тут несколько или один кому платить в итоге надо будет
100 рублей?
Не смеши меня.
Кидай деньги в монитор.
Меня завтра увольняют с поста главного инженера АСУ, можешь помолится за меня богу машине.
Ёб твою мать.
Я ещё удивлялся, какие хуесосы базы проектируют.
Узнал на скрине mysql workbench, думал чего годного накидаю. Посмотрел скрин и охуел.
Это просто пиздос!
И хуй бы с нормализацией, она для пидарасов придумана Для возмущающихся - пиздуйте гуглить CQRS + Event sourcing, а потом сразу к DDD и по тихому обтекаем, база не может диктовать ничего коду.. Ya your rot ebal, dumbass, в-общем.
Я ещё удивлялся, какие хуесосы базы проектируют.
Узнал на скрине mysql workbench, думал чего годного накидаю. Посмотрел скрин и охуел.
Это просто пиздос!
И хуй бы с нормализацией, она для пидарасов придумана Для возмущающихся - пиздуйте гуглить CQRS + Event sourcing, а потом сразу к DDD и по тихому обтекаем, база не может диктовать ничего коду.. Ya your rot ebal, dumbass, в-общем.
>И хуй бы с нормализацией, она для пидарасов придумана
Нормализация серьезно упрощает поддержку тому, кто будет держать базу. Как минимум разобраться проще.
Насчет диктовки: смотря с какого конца проектирование начинается, хотя я тоже топлю за Code first и DDD.
PEREDAI EMU CHTOBY SHEL NAHUI
Ребята, я полностью признаю, что еблан и 0. Поэтому и пришел за помощью.
Хуй знает что на пикче, лень разбиратся. Короче, делаешь в бд таблицы:
Работник - общая инфа, инн, имя, должность и т.д., обязательно id (int, ai), обязательно внешний ключ на отдел.
Контрагенты - тоже общая инфа типа инн, названия, id
Договора - тут тоже присваивается id, и обязательно поле orgid, в котором внешний ключ на id контрагента, ну и если надо, то всякие поля про оплату, можно тоже с внешними ключами на другие таблицы, ну там типа на таблицу с поступившими документами.
Дальше табличка с имеющимися отделами, там id и название отдела, инфа про должности и количество сотрудников тут не нужна.
Табличка о том какой отдел приступил к какому договору, там внешний ключ на id договора, внений ключ на id отдела.
Табличка о работниках, опять же внешний ключ на ид договора, поля для дат, вот эту хуйню ты видимо и хочешь. Про отдел тут не нужно, это есть в табличке о работнике. Но вообще ньюанс, работник может совмещать две должности, тогда тут уже надо отдел указать используя внешний ключ.
Как вариант можно две последние таблицы объединить в одну: внешние ключи на id договора, id отдела, id сотрудника, дата. Но этот вариант хуёвый, избыточность же.
Деньги отправь википедии.
Тебе не нужна связь между заданием и отделом.
Сотрудник уже содержит в себе ссылку на отдел, а в твоем задании важна детализация именно по сотрудникам.
мусклявый редактор под винду какой-то.
Дай бог здоровья. Ты хороший человек.
>Табличка о работниках приступивших, опять же внешний ключ на id договора, поля для дат, внешний ключ на id работника
Пофиксил
Можно ещё сделать табличку по заданиям, ну типа на договор может быть дано несколько заданий. Тогда делаешь аналогично, используя внешний ключ.
А вообще, иногда удобнее положить хуй на нф.
MySql WorkBench
департаменту же идёт ордер.
Ошибка в том, что ты пошел учиться на программиста.
Проиграл.
Это нигде не сказано. Если над заданием работают сотрудники разных отделов, то по ним легко собрать детализацию по отделам.
Чувак, не знаю ты ли был с самого начала, но мою хуйню со дна только вы и тащите
Двачую
Есь что почитать по этой теме для войтишника?
Блять это умно
по базам?
Ну да, а то я только про нормализацию знаю и немного про безопасность.
9 лет опыта, хуле.
Можешь Дейтом обмазаться, правда пишет тяжело, но обстоятельно.
Data Science. Наука о данных с нуля (на Pythone Обучение)
Системы баз данных. Полный курс
жеский, не думал преподавать?
Это вообще имеет теперь хоть какой то смысл?
>Системы баз данных. Полный курс
Толсто.
Нет, платят мало, а сертифицироваться мне лень.
Много лишних полей.
Из задания убери поля отдела и добавь внешний ключ на сотрудника.
Лучше даже так переделать.
Из задания убери поля отдела и добавь внешний ключ на сотрудника.
Лучше даже так переделать.
1) Если это ВСЕ условие задачи тогда я не понимаю зачем в базе столько лишних полей?
2) Названия полей и таблиц - пиздец.
3) За ким хуем для АТРИБУТА договора (дата заключения) отдельная таблица?
4)
>>если обращаются повторно, то скидка
Такие вещи обычно решаются программной логикой на стороне приложения, например при оформлении нового договора сотруднику в UI выводится список предыдущих договоров клиента и проставляется скидка, руками ли, или автоматом не важно. Кроме того, скидку лучше привязывать не к клиенту, а к договору, на случай если клиент попросит о нестандартной услуге, на которую скидка не предусмотрена.
5)
>>Так же вознаграждение за досрочное выполнение.
Где это у тебя и кто должен вознаграждаться? Если сотрудники, работающие над проектом, тогда нужна таблица "премии", с ключами к ИД сотрудника и ИД договора, ну и размеру премии разумеется.
6) Если ДОГОВОР и ПРОЕКТ это разные сущности и за одним договором может быть несколько проектов где табла с проектами?
ОП, ты слился?
Переделал по твоей схеме. А почему клиенты многие к одному договоры?
Добрые люди уже объяснили в чем я был не прав, стараюсь исправить
Не
предлагаю послать каширсскую нахуй
ой не то скинул
не тооооооооооооо скинул
Опчик, а как тебе такой вариант?
1) Есть клиент, у него может быть много договоров. Клиент - договор - один ко многим
2) У договора может быть только один способ оплаты. Справочник способов оплаты - договор - один к многим.
Скидка на заказ определяется на уровне приложения и пишется в discount.
3) За одним договором может быть несколько проектов. Договор - проекты - один к многим.
В проекте по колонке deadline определяем крайний срок сдачи.
4) На один проект может быть назначено много сотрудников разных отделов, допустим верстальщик, бекендер и дизайнер. Сл-но связываем проект с сотрудниками отношением многиие ко многим через таблицу employee_projects, в ней же фиксируем когда сотрудник заступил на проект и покинул его.
5) Ну и отдел - сотрудник, один отдел - много сотрудников, один к многим.
Если премии надо оформить в виде таблицы можешь доделать сам
Он лях, наверное, вот и пришел пшекать сюда.
Чувак дай телеграмм у меня полгруппы таких же, если хочешь подзаработать. Сколько возьмешь? Люблю тебя.
Ya bi blevanul na tabya no mne nechem
Та не, я уже работаю и мне хватает, но спасибо за предложение)
Попросил бы покамхворить, но тут все таки не натуралотред :3, по этому просто желаю удачи) На последок держи подарочек, няш) https://ru.files.fm/u/r62esed4
ахахах 2ch schema боже спасибо, что ты живешь, а то бы пизды получил от препода завтра :DD
Бля а у тебя внешние ключи не отображаются типа? Должны же серым ключом отмечаться не?
>DateOfDogovor
Рассмешил содомит
Есть организации, которые заказывают программное обеспечение. Есть компания, которая разрабатывает, в ней отделы и сотрудники. Организации могут заказать по одному договору несколько программных решений, если обращаются повторно, то скидка. Должно где-то отражаться, когда работник вступил в проект и, когда вышел. Так же вознаграждение за досрочное выполнение.