Таблица базы данных должна всегда иметь первичные ключи?
Попробуйте
<app-child (clickValidateAndSave)="handleClickOnChild($event)" ></app-child>
<div class="row col-mg-6">
<button type="submit" class="btn btn-primary" [disabled]="disableBtn"
[(ngModel)]="clickValidateAndSave">
Submit for Approval {{clickValidateAndSave}}
</button>
</div>
и в родительском js
disableBtn = false;
...
handleClickOnChild(bSuccess) {
this.disableBtn = !bSuccess
}
я пишу код из головы, чтобы он мог иметь некоторые ошибки
10 ответов
Вы должны стремиться иметь первичный ключ в любой нетривиальной таблице, где вы, вероятно, захотите получить доступ (или обновить или удалить) отдельные записи с помощью этого ключа. Первичные ключи могут состоять из нескольких столбцов, и формально это будет самый короткий из доступных суперключей; то есть самая короткая доступная группа столбцов, которые вместе однозначно идентифицируют любую строку.
Я не знаю, как выглядит схема базы данных Stack Overflow (и из некоторых вещей, которые я прочитал в блоге Джеффа, я не хочу), но в описанной вами ситуации вполне возможно, что в идентификаторе сообщения, номере версии и значении тега есть первичный ключ; конечно, это был бы самый короткий (и единственный) доступный суперключ.
Что касается вашего второго пункта, хотя может быть разумным выступить в пользу агрегирования значений в архивных таблицах, это противоречит принципу, согласно которому каждое пересечение строки / столбца в таблице должно содержать одно единственное значение. Хотя это может немного упростить разработку, нет причин, по которым вы не можете придерживаться нормализованной таблицы с версионными метаданными, даже для такой тривиальной задачи, как теги.
Я твердо уверен, что в каждой таблице должен быть способ уникальной идентификации записи. Для 99% таблиц это первичный ключ. В остальном вы можете получить уникальный индекс (я думаю, что один столбец ищет таблицы типов здесь). Всякий раз, когда мне приходилось работать с таблицей без способа уникальной идентификации записей, возникали проблемы.
Я также считаю, что если вы используете суррогатные ключи в качестве ПК, вы должны, где это возможно, иметь отдельный уникальный индекс для любой комбинации полей, составляющих естественный ключ. Я понимаю, что слишком много раз, когда ты не
Таблица должна иметь первичный ключ, чтобы вы могли однозначно идентифицировать каждую строку с его помощью.
Технически вы можете иметь таблицы без первичный ключ, но вы нарушите хорошие правила проектирования базы данных.
Я склонен согласиться с тем, что у большинства таблиц должен быть первичный ключ. Я могу вспомнить только два случая, когда это не имеет смысла.
- Если у вас есть таблица, которая связывает ключи с другими ключами. Например, чтобы связать user_id с answer_id, этой таблице не нужен первичный ключ.
- Таблица регистрации, единственная реальная цель которой - создать контрольный журнал.
В основном, если вы пишете таблицу на которые, возможно, когда-либо потребуется ссылаться в отношениях внешнего ключа, тогда важен первичный ключ, и если вы не можете быть уверены, что этого не будет, просто добавьте PK. :)
Если нет ПК , как вы обновите или удалите одну строку? Это было бы невозможно! Честно говоря, я использовал несколько таблиц умножения без PK, например, для хранения журналов активности, но даже в этом случае желательно иметь одну, потому что временные метки не могут быть достаточно детализированными. Временные таблицы - еще один пример. Но согласно теории отношений ПК является обязательным.
хорошо иметь ключи и связи. Очень помогает. однако, если ваше приложение достаточно хорошо для обработки отношений, вы можете пропустить ключи (хотя я рекомендую вам их иметь)
Поскольку я использую Subsonic, я всегда создаю первичный ключ для всех своих таблиц. Для работы многих библиотек абстракции БД требуется первичный ключ.
Примечание: это не отвечает тону вашего вопроса о «Великой унифицированной теории», но я просто говорю, что на практике иногда вы ДОЛЖНЫ создать первичный ключ для каждый стол.
См. Этот связанный вопрос о том, требуется ли целочисленный первичный ключ. В одном из ответов в качестве примера используется тегирование:
Существуют ли веские причины иметь таблицу базы данных без целочисленного первичного ключа
Дополнительное обсуждение тегов и ключей см. В этом вопросе:
Базы данных не имеют ключей как таковых, но составляющие их таблицы могут. Я полагаю, вы имеете в виду это, но на всякий случай ...
В любом случае, таблицы с большим количеством строк обязательно должны иметь первичные ключи; таблицы с несколькими строками не нуждаются в них обязательно, хотя и не вредят. Это зависит от использования и размера стола. Пуристы помещают первичные ключи в каждую таблицу. Это не так; и ни один из них не пропускает ПК в небольших таблицах.
Отредактировано, чтобы добавить ссылку на мою запись в блоге по этому вопросу, в которой я обсуждаю случай, когда администрация базы данных не сочла необходимым включать первичный ключ в определенную таблицу. Я думаю, это адекватно иллюстрирует мою точку зрения.
Если это таблица соединений, я бы не сказал, что вам нужен первичный ключ. Предположим, например, что у вас есть таблицы PERSONS, SICKPEOPLE и ILLNESSES. В таблице ILLNESSES есть такие вещи, как грипп, простуда и т. Д., Каждая из которых имеет первичный ключ. У PERSONS есть обычные сведения о людях, у каждого из которых есть первичный ключ. В таблице SICKPEOPLE есть только больные люди, и в ней есть два столбца: PERSONID и ILLNESSID, внешние ключи к соответствующим таблицам и нет первичного ключа. Таблицы PERSONS и ILLNESSES содержат сущности, а сущности получают первичные ключи. Записи в таблице SICKPEOPLE не являются сущностями и не получают первичных ключей.