Друг сказал мне, что я должен указать имя таблицы в поле имени той же таблицы, и мне интересно, почему? И должно быть так? Пример:
(Table) Users (Fields) user_id, username, password, last_login_time Я вижу, что префикс «user_» не имеет смысла, поскольку я знаю, что это уже для пользователя. Но я тоже хотел бы услышать от вас. note: Я программирую php, mysql.
Я с тобой согласен. Единственное место, где у меня возникает соблазн поставить имя таблицы или сокращенную форму, это первичный и внешний ключи или если «естественное» имя является ключевым словом.
Users: id or user_id, username, password, last_login_time Post: id or post_id, user_id, post_date, content
Обычно я использую «id» в качестве имени поля первичного ключа, но в этом случае я думаю, что user_id и post_id тоже в порядке. Обратите внимание, что дата публикации была названа «post_date», потому что «дата» – это ключевое слово.
По крайней мере, это моя конвенция. Ваш пробег может отличаться.
Я не вижу причины включать имя таблицы, это лишнее. В запросах вы можете ссылаться на поля как <имя таблицы>. <Имя поля> в любом случае (например, «user.id»).
При использовании таких общих полей, как 'id' и 'name', полезно добавить имя таблицы.
Причина в том, что это может сбивать с толку при написании объединений в нескольких таблицах.
Это личное предпочтение, на самом деле, но это аргументы позади (и я всегда так делаю).
Какой бы метод вы ни выбрали, убедитесь, что он согласован в рамках проекта.
Лично я не добавляю имена таблиц для имен полей в основной таблице, но при использовании в качестве чужого поля в другой таблице я буду префикс его с именем исходной таблицы. Например, поле id в таблице users будет называться id, но в таблице комментариев он, где комментарии связаны с пользователем, который их разместил, будет user_id.
Это я взял из схемы именования CakePHP, и я думаю, что это довольно аккуратно.
Префикс имени столбца с именем таблицы – это способ гарантировать уникальные имена столбцов, что упрощает объединение.
Но это утомительная практика, особенно если у нас есть длинные имена таблиц. Как правило, проще использовать псевдонимы, когда это необходимо. Кроме того, это не помогает, когда мы присоединяемся.
Как модератор данных, мне сложно постоянно быть последовательным. С столбцами ID я теоретически предпочитаю иметь только ID но обычно я нахожу, что у меня есть таблицы с столбцами USER_ID , ORDER_ID и т. Д.
Существуют сценарии, где можно положительно использовать общее имя столбца для нескольких таблиц. Например, когда отношение логического ITEM_STATUS было отображено как только дочерние таблицы, полезно сохранить столбец ITEM_STATUS во всех таблицах ITEM_STATUS (например, ITEM_STATUS ) вместо того, чтобы переименовывать его для каждой ITEM_STATUS ( ORDER_ITEM_STATUS , INVOICE_ITEM_STATUS и т. д.). Это особенно верно, когда они перечислены с общим набором значений.
Например, в вашей базе данных есть таблицы, в которых хранится информация о отделах продаж и отдела кадров, вы можете назвать все ваши таблицы, связанные с отделом продаж, как показано ниже:
SL_NewLeads SL_Territories SL_TerritoriesManager
Вы можете назвать все ваши таблицы, относящиеся к отделу кадров, как показано ниже:
HR_Candidates HR_PremierИнституты HR_InterviewSchedules
Такое соглашение об именах гарантирует, что все связанные таблицы сгруппированы вместе, когда вы перечислите все свои таблицы в алфавитном порядке. Однако, если ваша база данных имеет дело только с одной логической группой таблиц, вам не нужно использовать это соглашение об именах.
Обратите внимание, что иногда вы заканчиваете вертикальное разбиение таблиц на две или более таблиц, хотя эти разделы фактически представляют один и тот же объект. В этом случае добавьте слово, которое лучше всего идентифицирует раздел, для имени объекта
На самом деле, есть причина для такого наименования, особенно когда дело доходит до полей, вы, вероятно, присоединитесь к ним. В MySQL, по крайней мере, вы можете использовать ключевое слово USING вместо ON , а затем users u JOIN posts p ON p.user_id = u.id становится users u JOIN posts p USING(user_id) который является более чистым IMO.
Что касается других типов полей, вы можете извлечь выгоду при выборе * , потому что вам не нужно будет указывать список полей, которые вам нужны, и не забудьте указать, из какого поля выходит из этой таблицы. Но, как правило, использование SELECT * не рекомендуется на основе производительности и поддержки, поэтому я считаю, что префикс таких полей с табличным именем является плохой практикой, хотя он может отличаться от приложения к приложению.
Похоже, что вывод таков: если имя поля уникально для таблиц – префикс с именем таблицы. Если имя поля может быть дублировано в других таблицах, назовите его уникальным.
Я нашел имена полей, такие как «img, address, phone, year», поскольку разные таблицы могут содержать разные изображения, адреса, номера телефонов и годы.
Мы должны определить первичные ключи с префиксом tablename.
Мы должны использовать use_id вместо id и post_id вместо простого id.
Преимущества : –
1) Легко читаемый
2) Легко дифференцировать запросы на присоединение. Мы можем свести к минимуму использование псевдонима в запросе.
таблица пользователя: user_id (PK)
post table: post_id (PK) user_id (FK) здесь пользовательская таблица PK и столбец FK одинаковы
Согласно документации ,
3) Таким образом, мы можем получить выгоду от NATURAL JOIN и JOIN с помощью ИСПОЛЬЗОВАНИЯ
Естественные соединения и соединения с ИСПОЛЬЗОВАНИЕМ, включая варианты внешнего соединения, обрабатываются в соответствии со стандартом SQL: 2003. Целью было согласование синтаксиса и семантики MySQL в отношении NATURAL JOIN и JOIN … ИСПОЛЬЗОВАНИЕ в соответствии с SQL: 2003. Однако эти изменения в обработке соединений могут приводить к разным выходным столбцам для некоторых объединений. Кроме того, некоторые запросы, которые, как представляется, корректно работают в старых версиях (до 5.0.12), должны быть переписаны в соответствии со стандартом.
Эти изменения имеют пять основных аспектов:
1) Способ, которым MySQL определяет столбцы результатов операций NATURAL или USING join (и, следовательно, результат всего предложения FROM).
2) Расширение SELECT * и SELECT tbl_name. * В список выбранных столбцов.
3) Разрешение имен столбцов в NATURAL или USING.
4) Преобразование NATURAL или USING соединений в JOIN … ON.
5) Разрешение имен столбцов в состоянии ВКЛ. СОЕДИНЕНИЯ … ВКЛ.
Примеры:-
SELECT * FROM user NATURAL LEFT JOIN post; SELECT * FROM user NATURAL JOIN post; SELECT * FROM user JOIN post USING (user_id);