Друг сказал мне, что я должен указать имя таблицы в поле имени той же таблицы, и мне интересно, почему? И должно быть так? Пример:
(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) вместо того, чтобы переименовать его для каждый подтип (ORDER_ITEM_STATUS, INVOICE_ITEM_STATUS и т.д.). Это особенно верно, когда они перечислены с общим набором значений.
Например, в вашей базе данных есть таблицы, в которых хранятся сведения о отделах продаж и отдела персонала, вы можете назвать все ваши таблицы, относящиеся к отделу продаж, как показано ниже:
SL_NewLeads SL_Territories SL_TerritoriesManagers
Вы можете назвать все ваши таблицы, относящиеся к отделу кадров, как показано ниже:
HR_Candidates HR_PremierInstitutes 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). Таким образом, мы можем получить выгоду ПРИРОДНЫЙ ПРИСОЕДИНЯЙТЕСЬ И ПРИСОЕДИНЯЙТЕСЬ с ИСПОЛЬЗОВАНИЕМ
Естественное объединение и объединение с ИСПОЛЬЗОВАНИЕМ, включая варианты внешнего соединения, обрабатывается в соответствии со стандартом SQL: 2003. Целью было выровнять синтаксис и семантика MySQL в отношении NATURAL JOIN и ПРИСОЕДИНИТЕСЬ... ИСПОЛЬЗОВАНИЕ в соответствии с SQL: 2003. Однако эти изменения в объединении обработка может привести к разным выходным столбцам для некоторых объединений. Кроме того, некоторые запросы, которые, как представляется, корректно работают в старых версиях (до 5.0.12) должны быть переписаны в соответствии со стандартом.
Эти изменения имеют пять основных аспектов:
1) Способ, которым MySQL определяет столбцы результатов NATURAL или USING операций объединения (и, следовательно, результат всего предложения FROM).
2) Расширение SELECT * и SELECT tbl_name. * в список выбранных столбцов.
3) Разрешение имен столбцов в приложениях NATURAL или USING.
4) Преобразование NATURAL или USING соединений в JOIN... ON.
5) Разрешение имен столбцов в состоянии ON для JOIN... ON.
Примеры: -
SELECT * FROM user NATURAL LEFT JOIN post;
SELECT * FROM user NATURAL JOIN post;
SELECT * FROM user JOIN post USING (user_id);