Что важно для учета при разработке базы данных?
Если вы хотите использовать класс Parent в подклассе, класс Child, то вам нужно сделать следующее:
class Parent {
foo() {
console.log('foo!');
}
}
class Child extends Parent {
constructor() {
super();
}
}
let c = new Child(); //instantiate Child class
c.foo(); // here you are calling super.foo(); which is the Parent classes method for foo.
//foo!
Ключевое слово super используется для доступа и вызывать функции у родителя объекта.
blockquote>Или, в качестве альтернативы, если вы предпочитаете создать метод в дочернем классе, который заключает в себе родительский метод foo, а не доступ это путем создания экземпляра родительского класса с помощью вызова
superв дочернем конструкторе:class Parent { foo() { console.log('foo!'); } } class Child extends Parent { method() { this.foo(); } } let c = new Child(); c.method();
21 ответ
"Нормализуйте, пока это не причинит боль; денормализуйте, пока это не будет работать".
Я знаю, что это было указано, но нормализация, нормализация, нормализация является ключом. Если существует экземпляр, где Вы чувствуете, что по любой причине, что необходимо хранить данные в ненормализованном формате, не делайте этого. Это должно быть обработано посредством представлений или в отдельной базе данных создания отчетов. Мой другой ключевой совет состоит в том, чтобы избежать text/ntext полей по мере возможности.
Данные Вечны. Обработка Приходит и уходит.
Заставляют реляционную модель быть высокочастотным представлением реального мира. Это имеет значение больше, чем что-либо еще.
Обработка изменится и разовьется в течение многих лет. Но Ваши данные - и модель данных - не могут развиться в том же темпе и с той же гибкостью. Можно добавить обработку, но Вы не можете волшебно добавить информацию. Вы не хотите удалять информацию (но можно проигнорировать ее.)
Получают право модели . Объекты и отношения в Ваших схемах должны иметь рациональный смысл случайному нетехническому пользователю. Даже прикладное программирование должно быть простым, четким и точным.
, Если Вы боретесь с моделью, не изобретайте большие, сложные запросы или (худшие) хранимые процедуры для работы вокруг проблем. Процедурные обходные решения являются дорогостоящей ошибкой. Поймите то, что Вы имеете, что Вы хотите сделать и применить принцип YAGNI для срезания вещей к основам.
С тех пор было несколько сообщений, защищающих это теперь, я добавлю еще одну вещь...
не попадают в прерывание помещения столбцов ID на всех Ваших таблицах. Существует много ОЧЕНЬ серьезных оснований, почему современная теория проектирования баз данных использует реальные первичные ключи, и они не строго академические причины. Я работал с базами данных, которые включали сотни таблиц, многие из которых были многомиллионными таблицами строки с более чем 1 000 параллельных пользователей и использования реальных первичных ключей, не "сломался".
столбцы Using ID на всех Ваших таблицах означают, что необходимо будет сделать, мультитаблица соединяет для пересечения через базу данных, которая становится большой стычкой. Это также имеет тенденцию способствовать неаккуратному проектированию баз данных, и даже кроме того часто приводит к проблемам с дублирующимися строками. Другая проблема - то, что при контакте с внешними системами теперь необходимо передать эти идентификаторы вокруг.
существуют места для суррогатных идентификаторов - кодовые таблицы типа и концептуальные таблицы (например, таблица системных правил могла использовать идентификатор, если правила не имеют реальных идентификаторов). Используя их везде ошибка IMO.
Это - давние дебаты, но это - мое мнение о вопросе, если это имеет значение.
Получите действительно хорошую книгу по моделированию данных - один записанный истинным разработчиком базы данных, не разработчиком.NET, который пытается учить Вас, как оно сделано в "реальном мире".
пространство задач проектирования баз данных является просто слишком большим, чтобы быть значительно покрытым форумом как это. Несмотря на это, хотя, я дам Вам несколько персональных подсказок:
Слушают вышеупомянутые сообщения о нормализации. НИКОГДА не денормализовывайте, потому что Вы ДУМАЕТЕ, что имеете к по причинам производительности. Необходимо только денормализовать после того, как у Вас будет опыт фактические проблемы производительности (идеально в Вашей среде QA, не производстве). Даже затем полагайте, что может быть лучший способ записать Ваши запросы или улучшить индексацию сначала.
Ограничивают данные как можно больше. Столбцами должен быть NOT NULL как можно больше. Используйте ограничения CHECK и ВНЕШНИЕ КЛЮЧИ везде, где они должны быть. Если Вы не сделаете этого, то неправильные данные будут входить в Вашу базу данных и вызывать большое программирование особого случая и головные боли.
Продумывают Ваши данные, прежде чем Вы на самом деле начнете разрабатывать таблицы. Хорошо разберитесь, как будут течь Ваши процессы и какие данные они должны будут отследить. Часто времена, что Вы думаете, являются объектом, на первый взгляд оказывается двумя объектами. Как пример, в системе, что я продолжаю работать, предыдущий разработчик создал Таблицу-участник, и всей информацией из их приложения была часть Таблицы-участника. Оказывается, что участник мог бы хотеть изменить данные, которые были на их приложении, но мы все еще должны отследить то, на что было похоже исходное приложение, таким образом, Приложение является действительно своим собственным объектом, и участник является объектом, который мог бы первоначально быть заполнен из Приложения. Короче говоря, сделайте обширный анализ данных, только начните составлять таблицы.
Некоторые вещи я имел бы в виду. Удостоверьтесь, что каждая таблица имеет способ однозначно определить записи (Вы сохраните невыразимые часы боли, делающей это). Нормализуйте, но не присоединяйтесь на больших многостолбцовых естественных ключах, если Вы не хотите, чтобы все это было медленно. Используйте числовой ключ, который автоматически генерируется в родительской таблице вместо этого.
Да, думайте о видах запросов, и сообщает, что необходимо будет работать. Думайте о расширяемости. На Вас может казаться, что wan't нужны больше чем 10 столбцов продуктов в таблице порядка, но что происходит, когда Вам нужно 11. Лучше иметь таблицу порядка и таблицу детали заказа.
Удостоверяются, что все правила целостности данных включены в базу данных. Не все изменения данных происходят от пользовательского интерфейса, и я должен был попытаться зафиксировать, слишком многие плохо испортили базы данных, потому что разработчики полагали, что было нормально помещать все правила в GUI.
самые критические вещи рассмотреть, когда desiging являются первыми, как гарантировать целостность данных (если данные бессмысленны затем, база данных является бесполезной) и второй, как гарантировать производительность. Не используйте объектную модель для разработки реляционной базы данных, если Вы не хотите плохую производительность.
следующей самой важной вещью является защита данных и безопасность. У пользователей никогда не должно быть прямого доступа к таблицам базы данных. Если Ваш дизайн требует динамического SQL, у них должен будет быть тот доступ. Это плохо с точки зрения потенциального взламывания в через вещи как атаки с использованием кода на SQL, но что еще более важно, оно открывается, Ваша база данных для внутренних людей совершают мошенничество. Есть ли поля, где необходимо зашифровать данные (данные кредитной карты, пароли, и Номера социального страхования среди объектов, которые никогда не должны храниться незашифрованные). Как Вы планируете сделать это и как Вы планируете контролировать дешифрование, чтобы гарантировать, что люди не дешифруют, когда у них нет потребности видеть данные. Есть ли легальные обручи, которые необходимо пройти ( HIPPA и , Sarbanes Oxley приходит на ум)?
Попытайтесь вообразить SQL-запросы, которые Вы формуете против него.
Это важно, потому что Вы сделаете это МНОГО!
Удостоверьтесь, что Вы используете ограничения (CHECK, NOT NULL, FOREIGN KEY, PRIMARY KEY, и DEFAULT), чтобы гарантировать, что только корректные данные хранятся в базе данных во-первых. Можно всегда покупать более быстрые аппаратные средства, но Вы не можете купить более корректные данные.
Установите последовательные стандарты именования заранее. Это сохранит несколько минут ненужных взглядов в конечном счете. (Это может читать как ирония, но я серьезен.)
И ничего не сокращают, если это не чрезвычайно распространено. Не превращайте базу данных в сообщение номерного знака, предполагая игру. Удивительно, что становится не - очевидным после года.
(Принятие OLTP)
Нормализация Ваших структур данных. (Денормализации производительности могут обычно , следуют позже при необходимости)
Я сказал бы, что важная вещь иметь в виду состоит в том, что структура может измениться. Не разрабатывайте себя в угол. Удостоверьтесь, что Вы делаете оставляет Вас некоторой "комнатой" и даже авеню для миграции данных в другую структуру однажды.
Помните, что нормализация только относительно того, что Вы моделируете. Возможно, Вы моделируете набор объектов в Вашем домене. Возможно, Вы записываете серию событий, в которых повторяются данные, потому что те же данные, оказывается, применяются больше чем в один раз. Не перепутывайте эти две вещи.
Не используйте большой набор столбцов как первичные ключи
Я соглашаюсь, что знание о Ваших данных хорошо и нормализует.
Что-то еще, что я предложил бы, должно сохранить файлы очень крупного текста в отдельной таблице. Например, если у Вас есть контракт, Вы могли бы хотеть хранить большую информацию о контракте в одной таблице, но сохранить легальное (и очень большой) документом в отдельной таблице. Просто вставьте индекс от основной таблицы в легальный документ.
Поймите требования так, как Вы возможно можете впереди. Затем разработайте логическую схему, которая должна будет только измениться, если требования изменяются, или если Вы мигрируете на совершенно другой вид базы данных, как та, которая не использует SQL. Затем совершенствуйте и расширьте свой дизайн в физический дизайн, который принимает во внимание Ваш конкретный продукт DBMS, Ваш объем, Вашу загрузку и Ваши требования к скорости.
Изучают, как нормализовать, но также и изучить, когда повредить правила нормализации.
Удостоверьтесь, что как можно больше метаданных кодируется в модели. Должно быть возможно вывести почти любое бизнес-правило или понятие от просто рассмотрения модели данных.
Это означает, заботьтесь для выбора имен, которые отражают действительность пользователей (но не бойтесь изменить их восприятие действительности, если это помогает модели).
Кодируют все ограничения, Вы можете в базе данных. Не полагайтесь на прикладной уровень, чтобы только снабдить разумными данными. Удостоверьтесь, что только разумные данные могут существовать во-первых.
не делают агрегированных данных в модели. Сохраните модель максимально атомарной. Или агрегат на лету или выполненные регулярные задания агрегирования в сводные таблицы.
Выбор хороший раздел между схемами. Некоторое разделение имеет смысл делать с внешними ключами и некоторыми чистым физическим разделением.
Я сильно отзываюсь эхом, та нормализация очень важна с тактической денормализацией для следования для производительности или других причин пригодности для обслуживания. Однако, если бы Вы ожидаете иметь больше, чем всего несколько таблиц, я хотел бы предложить один протест о нормализации, которая сделает Вашу жизнь намного легче, когда количество таблиц растет.
протест состоит в том, чтобы сделать первичный ключ для каждой таблицы единственным числовым столбцом (подходящий для Вашей разновидности DB). В академической нормализации идея состоит в том, чтобы объединить любые атрибуты (столбцы) объекта (таблица) так, чтобы можно было однозначно определить экземпляр того, что описывается (строка), и можно закончить с многостолбцовым составным первичным ключом. Таким образом каждый раз, когда Вы перемещаете тот составной ключ как внешний ключ к другим таблицам, Вы заканчиваете тем, что копировали те несколько столбцов в каждый таблица, которая ссылается на него. Это могло бы работать на Вас, если у Вас только есть полдюжины таблиц. Но это разваливается быстро, когда Вы идете намного более крупные, чем это.
Так вместо многостолбцового составного первичного ключа, пойдите с последовательным числовым первичным ключом даже при том, что тот подход идет вразрез с некоторыми строгими учениями нормализации.
Это на Объектно-ориентированный язык? Так попытайтесь моделировать свои объекты перед базой данных. Это поможет Вам сфокусироваться на модели.
Если у Вас есть запросы, что Вы собираетесь быть выполнением МНОГО, превращаете их в хранимые процедуры. Они будут почти всегда выполняемые быстрее.
При поиске строк полями кроме первичного ключа удостоверьтесь, что индексировали их.
«Правило большого пальца для баз данных - вниз всегда важнее!»
Примеры: Если у вас есть таблица клиентов со столбцами для почтового адреса, адреса доставки и платежного адреса ... Создайте отдельную таблицу CustomerAddress с типом адреса
. Если у вас есть таблица CancellationDetails с CancellationReason01, CancellationReason02, CancellationReason03 .. создайте отдельную CancellationReason стол