Cody O'Meara Ответов: 1

Расчесывание 2 разных таблиц с реальным, данные

У меня есть 2 таблицы MySQL. Один из них - это форма на моем сайте, которая отправляется. Вторая - это библиотека всех сотрудников и их отделов. Скриншоты прилагаются

Первый Стол
1-я таблица формы представления

вторая таблица
2-й стол "библиотека"

Поэтому в принципе я хотел бы показать все данные в таблице 1 вместе с тем, чтобы отдел из таблицы 2 находился в конце строки таблицы 1 на основе общего имени. Так ведь прогресс на переговорах по Греции колонке, я хотел бы видеть Департамента, что видовое название, сведения полное имя.

Это, очевидно, не совсем правильное утверждение, но может помочь объяснить, что я пытаюсь сделать,
SELECT results.fullName, employees.department, results.result, results.data1 where results.fullName = employees.name


Спасибо за любую помощь!

Что я уже пробовал:

Я посмотрел на соединение и внутреннее соединение, но оба они не сочетались. Это похоже на то, что он показывал только общие данные между 2 таблицами, основанными на имени, и исключал любые несвязанные совпадения, а это не то, что я хочу.

1 Ответов

Рейтинг:
6

OriginalGriff

Ваш дизайн стола нуждается в работе:
1) пока он будет работать - некоторое время - используя fullName поскольку уникальный ключ для идентификации строки очень несовершенен, отчасти потому, что он неэффективен, но в основном потому, что они очень редко уникальны: по мере роста числа людей в вашей БД растет и вероятность того, что два пользователя будут иметь одинаковые имена: это очень, очень распространено! Как только это происходит, целостность ваших данных выходит из окна, и весь ваш дизайн терпит крах. Всегда используйте столбец идентификатора строки, который должен быть "главным индексом" для ваших табличных данных.
2) также очень неэффективно хранить одни и те же данные в нескольких местах: "Коди Омеара" появляется по крайней мере в двух местах (и это занимает место), и так будет отдел. Если пользователь меняет свое имя - например, когда он женится - или отделы разделяются или объединяются, вам нужно изменить его в нескольких местах, и это одновременно сложно и опасно. Существует также риск того, что разные таблицы будут иметь немного разные данные, которые должны быть одинаковыми: "Коди Омеара" и "Коди О'мира", возможно, или "Коди Омеара". Ваш код должен справляться со всеми возможными вариациями, иначе целостность данных снова нарушится, как и ваше приложение.
3) ваша таблица "библиотека" бесполезна как отдельная таблица - она содержит один элемент, который должен храниться в пользовательской таблице, если только пользователь не может быть частью нескольких отделов - в этом случае становится еще менее эффективным использовать полное имя в качестве ключа.
4) не вызывайте столбцы по ключевым словам: DATETIME-это тип данных в SQL, поэтому вы не должны использовать его для имени столбца: "Timestamp", "EnterDate" или "JoinedOn" - это месиво лучше, в зависимости от того, что означают данные, которые они содержат. Аналогично для "data1", "data2", ... "data6" вы должны использовать имена, описывающие то, что содержит столбец, а не общее имя, которое не помогает вашему коду быть легко читаемым.

Поэтому добавьте идентификационные строки в свои таблицы, используйте eteh ID в качестве первичного ключа для идентификации строки, а затем вы можете без проблем объединить данные:
Пользователи:

ID            INT, IDENTITY (Or UNIQUEIDENTIFIER, depending on your preference)
fullName      NVARCHAR
timeStamp     DATATIME2
...
Библиотека:
ID           INT, IDENTITY (Or UNIQUEIDENTIFIER, depending on your preference)
UserID       INT, IDENTITY (Or UNIQUEIDENTIFIER, match it with the Users ID)
DeptID       INT, IDENTITY (Or UNIQUEIDENTIFIER, match it with the Departments ID)
Отделы:
ID           INT, IDENTITY (Or UNIQUEIDENTIFIER, depending on your preference)
Name         NVARCHAR

И соединить их вместе:
SELECT u.fullNAme, u.TimeStamp, d.Name
FROM Users u
JOIN Library l ON u.ID = l.UserID
JOIN Departments d ON l.DeptID = d.ID

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