Что каждый разработчик должен знать о базах данных? [закрытый]

Нравится нам это или нет, многие, если не большинство из нас разработчики или регулярно работают с базами данных или, вероятно, придется работать с одной когда-нибудь. И рассматривая сумму неправильного употребления и злоупотребления в дикой природе, и объема связанных с базой данных вопросов, которые подходят каждый день, справедливости ради стоит отметить, что существуют определенные понятия, которые разработчики должны знать - даже если они не разрабатывают или работают с базами данных сегодня. Так:



Каковы важные понятия, которые разработчики и другие профессионалы программного обеспечения должны знать о базах данных?


Инструкции для ответов:


Сохраните свой список коротким.
Одно понятие на ответ является лучшим.

Будьте конкретны.
"Моделирование данных" может быть важным навыком, но что это означает точно?

Объясните свое объяснение.
Почему Ваше понятие важно? Только скажите "индексы использования". Не попадайте в "лучшие практики". Убедите, что Ваша аудитория для движения узнает больше.

Upvote отвечает, что Вы соглашаетесь с.
Прочитайте ответы других людей сначала. Один высоко оцениваемый ответ является более эффективным оператором, чем два низко оцениваемых. Если у Вас есть больше, чтобы добавить, или добавить комментарий или сослаться на оригинал.

Не делайте downvote что-то просто, потому что он не относится к Вам лично.
Все мы работаем в различных доменах. Цель здесь состоит в том, чтобы предоставить направление новичкам базы данных, чтобы получить обоснованное, всестороннее понимание проектирования баз данных и управляемой базой данных разработки, не конкурировать за заголовок большинства - важный.

205
задан 3 revs 30 December 2009 в 16:02
поделиться

29 ответов

Первое, что разработчики должны знать о базах данных, это то, что они должны знать: для чего нужны базы данных ? Ни как они работают, ни как вы их строите, ни даже как вы пишете код для получения или обновления данных в базе данных. Но для чего они нужны?

К сожалению, ответ на этот вопрос - движущаяся мишень. В хайдее баз данных с 1970-х по начало 1990-х годов базы данных предназначались для обмена данными Если вы пользовались базой данных и не обменивались данными, вы либо были вовлечены в академический проект, либо тратили впустую ресурсы, в том числе и на себя. Настройка базы данных и укрощение СУБД были настолько монументальными задачами, что окупаемость с точки зрения данных, используемых многократно, должна была быть огромной, чтобы соответствовать вложенным средствам

За последние 15 лет базы данных стали использоваться для хранения постоянных данных, связанных только с одним приложением. Построение баз данных для MySQL, или Access, или SQL Server стало настолько рутинным, что базы данных стали почти рутинной частью обычного приложения. Иногда эта изначально ограниченная миссия сдвигается вверх под действием ползучести миссии, по мере того, как становится очевидным реальное значение данных. К сожалению, базы данных, которые были спроектированы с единственной целью, часто терпят крах, когда их начинают толкать на роль, которая является критической для предприятия и миссии.

Второе, что разработчикам необходимо знать о базах данных - это весь мир , ориентированный на данные . Взгляд на мир, ориентированный на данные, больше отличается от взгляда на мир, ориентированный на процессы, чем что-либо, что когда-либо узнавали большинство разработчиков. По сравнению с этим пробелом, разрыв между структурированным и объектно-ориентированным программированием относительно невелик.

Третье, чему разработчикам необходимо научиться, по крайней мере в обзоре, - это моделированию данных, включая концептуальное моделирование данных, логическое моделирование данных, моделирование физических данных.

Моделирование концептуальных данных - это действительно анализ требований с точки зрения моделирования данных.

Логическое моделирование данных - это, как правило, применение конкретной модели данных к требованиям, обнаруженным при моделировании концептуальных данных. Реляционная модель используется гораздо чаще, чем любая другая специфическая модель, и разработчикам необходимо обязательно изучить реляционную модель. Проектирование мощной и релевантной реляционной модели для нетривиальных требований не является тривиальной задачей. Нельзя строить хорошие таблицы SQL, если неправильно понимать реляционную модель.

Физическое моделирование данных, как правило, специфично для СУБД и не нуждается в подробном изучении, если только разработчик не является также и сборщиком СУБД или ЦОД. Разработчикам необходимо понять, в какой степени физическое проектирование СУБД можно отделить от логического проектирования БД, и степень, в которой создание высокоскоростной базы данных может быть достигнуто только путем отладки физического дизайна.

Следующее, что разработчики должны узнать, это то, что , в то время как скорость (производительность) важна, другие меры дизайнерского мастерства еще более важны , такие как возможность пересмотра и расширения области применения базы данных в дальнейшем, или простота программирования.

Наконец, любой, кто имеет дело с базами данных, должен понимать, что значение данных часто превосходит систему, которая их захватила .

Ух ты!

105
ответ дан 23 November 2019 в 04:52
поделиться

Для некоторых проектов, и модель, ориентированная на объект, лучше.

Для других проектов, реляционная модель лучше.

.
1
ответ дан 23 November 2019 в 04:52
поделиться
  • Basic SQL skills.
  • Индексирование.
  • Работа с различными воплощениями документации DATE/ TIME/ TIMESTAMP.
  • JDBC driver для используемой вами платформы.
  • Работа с бинарными типами данных (CLOB, BLOB и т.д. )
2
ответ дан 23 November 2019 в 04:52
поделиться

Я думаю, что здесь описано много технических деталей, и я не хочу к ним добавлять. Единственное, что я хочу сказать - это больше социальное, чем техническое, не попадайтесь на ловушку "DBA зная лучшее", как разработчик приложений.

Если у вас проблемы с производительностью при запросе, возьмите проблему в свои руки. Проведите собственное исследование и попросите DBA объяснить, что происходит и как их решения решают проблему.

Придумайте также свои собственные предложения после того, как вы закончите исследование. То есть я стараюсь найти совместное решение проблемы, а не оставлять вопросы, связанные с базами данных, на усмотрение АБД

.
5
ответ дан 23 November 2019 в 04:52
поделиться

Предотвращение SQL инъекций и как обеспечить безопасность вашей базы данных

.
11
ответ дан 23 November 2019 в 04:52
поделиться

Я бы сказал, сильные базовые навыки SQL. До сих пор я видел много разработчиков, которые немного знают о базах данных, но всегда спрашивают совета, как сформулировать достаточно простой запрос. Запросы не всегда так просты и легки. При запросе к хорошо нормализованной базе данных нужно использовать несколько соединений (внутреннее, левое и т.д.)

.
5
ответ дан 23 November 2019 в 04:52
поделиться

Я бы хотел, чтобы все, как DBA, так и разработчики/дизайнеры/архитекторы, лучше понимали, как правильно моделировать бизнес домен, и как сопоставить/перевести эту модель бизнес домена как в нормализованную логическую модель базы данных, оптимизированную физическую модель, так и в соответствующую объектно-ориентированную классовую модель, каждая из которых (может быть) различна, по разным причинам, и понимали, когда, почему, и как они (или должны быть) различны друг от друга

.
5
ответ дан 23 November 2019 в 04:52
поделиться

Эволюционный дизайн базы данных. http://martinfowler.com/articles/evodb.html

Эти гибкие методологии делают процесс изменения базы данных управляемым, предсказуемым и тестируемым.

Разработчики должны знать, что требуется для рефакторинга производственной базы данных с точки зрения контроля версий, непрерывной интеграции и автоматизированного тестирования.

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

По крайней мере, знайте, что концепция и методологии рефакторинга базы данных существуют. http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Классификация и описание процесса позволяют реализовать и инструментарий для этих рефакторингов.

.
6
ответ дан 23 November 2019 в 04:52
поделиться

Каждый разработчик должен знать, что это ложь: "Профилирование операции с базой данных полностью отличается от профилирования кода"

В традиционном смысле есть четкий Big-O. Когда вы делаете EXPLAIN PLAN (или эквивалент), вы видите алгоритм. Некоторые алгоритмы включают вложенные циклы и составляют O( n ^ 2). Другие алгоритмы включают в себя поиск B-дерева и составляют O( n log n ).

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

Если вы не уверены в используемом алгоритме, сделайте следующее. Остановитесь. Объяснить план выполнения запроса. Настройте индексы соответственно.

Также, следствие: Больше индексов не лучше.

Иногда индекс, сфокусированный на одной операции, замедляет другие операции. В зависимости от соотношения двух операций, добавление индекса может иметь хороший эффект, не оказать общего влияния, или нанести вред общей производительности.

9
ответ дан 23 November 2019 в 04:52
поделиться

Помимо синтаксиса и концептуальных опций, которые они используют (таких как соединения, триггеры и хранимые процедуры), для каждого разработчика, использующего базу данных, важно следующее:

Знайте, как ваш движок будет выполнять запрос, который вы пишете со спецификой.

Причина, по которой я думаю, что это так важно, это просто производственная стабильность. Вы должны знать, как работает ваш код, чтобы не останавливать все выполнение в потоке, пока вы ждете завершения длинной функции, так почему же вы не хотите знать, как ваш запрос повлияет на базу данных, вашу программу и, возможно, даже на сервер?

Это на самом деле то, что поразило мою команду разработчиков больше раз, чем пропущенные точки с запятой или что-то в этом роде. Предположительно, запрос будет выполняться быстро, потому что он делает это в системе разработки с несколькими тысячами строк в таблицах. Даже если производственная база данных одного и того же размера, она, скорее всего, будет использоваться гораздо чаще, и, следовательно, пострадает от других ограничений, таких как одновременный доступ к ней нескольких пользователей, или что-то не так с другим запросом в другом месте, таким образом, задерживая результат этого запроса.

Даже такие простые вещи, как то, как соединения влияют на производительность запроса, бесценны в производстве. Есть много особенностей многих движков БД, которые концептуально облегчают работу, но могут привнести в работу готические моменты, если не думать об этом четко.

Знайте процесс выполнения движка БД и планируйте его.

.
3
ответ дан 23 November 2019 в 04:52
поделиться

Нормализация

Меня всегда угнетает, когда я вижу, как кто-то пытается написать чрезмерно сложный запрос, который был бы абсолютно простым с нормализованным дизайном ("Покажите мне общий объем продаж по региону.")

Если вы поймете это в самом начале и соответственно спроектируете, то избавите себя от большой боли позже. После того, как вы нормализовались, легко денормализовать для производительности; не так просто нормализовать базу данных, которая с самого начала не была спроектирована таким образом.

По крайней мере, вы должны знать, что такое 3NF и как туда попасть. Для большинства транзакционных баз данных это очень хороший баланс между простотой записи запросов и поддержанием хорошей производительности

.
16
ответ дан 23 November 2019 в 04:52
поделиться

Базовая индексация

Я всегда шокирован, когда вижу таблицу или целую базу данных без индексов или произвольных/неиспользуемых индексов. Даже если вы не проектируете базу данных и просто должны написать несколько запросов, все равно жизненно важно понять, как минимум:

  • Что индексируется в вашей базе данных, а что нет:
  • Разница между типами сканирования, как они выбираются и как вы пишете запрос, может повлиять на этот выбор;
  • Концепция покрытия (почему вы не должны просто писать SELECT *);
  • Разница между кластерным и некластерным индексом;
  • Почему больше/большие индексы не обязательно лучше;
  • Почему вы должны стараться избегать обертывания столбцов фильтра в функциях.

Дизайнеры также должны знать о распространенных антимаскировочных индексах, например:

  • The Access-pattern (индексирование каждого столбца, один за другим)
  • The Catch-All антимаскировочный (один массивный индекс на все или большинство столбцов, созданный, очевидно, под ошибочным впечатлением, что он ускорит каждый мыслимый запрос, затрагивающий любой из этих столбцов).

Качество индексирования базы данных и то, используете ли вы его вместе с пишущими запросами или нет, составляет на сегодняшний день самую значительную часть производительности. 9 из 10 вопросов, заданных на SO и других форумах, жалующихся на плохую производительность, неизменно оказываются из-за плохой индексации или неразборчивого выражения.

.
19
ответ дан 23 November 2019 в 04:52
поделиться

О следующем комментарии к ответу Уолтера М.:

"Очень хорошо написано! И историческая перспектива замечательна для людей, которые в то время (т.е. для меня) не занимались работой с базами данных"

Историческая перспектива в определенном смысле абсолютно критична. "Те, кто забывают историю, обречены ее повторить." Cfr XML, повторяющий иерархические ошибки прошлого, графовые БД, повторяющие сетевые ошибки прошлого, системы ОП, навязывающие иерархическую модель пользователям, в то время как все, у кого есть хотя бы десятая часть мозга, должны знать, что иерархическая модель не подходит для универсального представления реального мира, etcetera, etcetera.

Что касается самого вопроса:

Каждый разработчик БД должен знать, что "реляционная" модель не равна "SQL". Тогда они поймут, почему их так абстрактно подводят вендоры СУБД, и почему они должны говорить этим же вендорам придумывать что-то лучшее (например, реляционные СУБД), если они хотят продолжать высасывать уморительные суммы денег из своих заказчиков за такое дерьмовое ПО)

И каждый разработчик СУБД должен знать о реляционной алгебре все, что угодно. Тогда больше не осталось бы ни одного разработчика, которому пришлось бы выкладывать эти дурацкие вопросы "Я не знаю, как делать свою работу, и хочу, чтобы кто-нибудь другой делал это за меня" на Stack Overflow

.
5
ответ дан 23 November 2019 в 04:52
поделиться

Хороший вопрос. Некоторые мысли не в определенном порядке:

  1. Нормализация, по крайней мере, до второй нормальной формы, существенна.

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

  3. Хорошее и правильное использование контрольных ограничений. Пусть БД делает как можно больше работы.

  4. Не разбрасывайте бизнес-логику как в БД, так и в коде среднего уровня. Выбирайте тот или иной, желательно в коде среднего уровня.

  5. Решайте вопрос о последовательном подходе для первичных и кластерных ключей.

  6. Не переусердствуйте. Выбирайте индексы с умом.

  7. Последовательное наименование таблиц и столбцов. Выберите стандарт и придерживайтесь его.

  8. Ограничить количество столбцов в БД, которые будут принимать нулевые значения.

  9. Не увлекайтесь триггерами. Они имеют свое применение, но могут усложнить ситуацию в спешке.

  10. Будьте осторожны с UDF. Они великолепны, но могут вызвать проблемы с производительностью, когда вы не знаете, как часто они могут вызываться в запросе.

  11. Получите книгу Селко о дизайне БД. Человек высокомерен, но знает свои вещи.

72
ответ дан 23 November 2019 в 04:52
поделиться

Хочу лишь отметить наблюдение - то есть кажется, что большинство ответов предполагает, что база данных взаимозаменяема с реляционными базами данных. Есть также объектные базы данных, плоские файловые базы данных. Важно оценить потребности рассматриваемого программного проекта. С точки зрения программиста решение о базе данных может быть отложено на более поздний срок. Моделирование данных, с другой стороны, может быть достигнуто на ранней стадии и привести к большому успеху.

Я думаю, что моделирование данных является ключевым компонентом и относительно старой концепцией, тем не менее, это концепция, которая была забыта многими в индустрии программного обеспечения. Моделирование данных, особенно концептуальное моделирование, может раскрыть функциональное поведение системы и на него можно положиться как на "дорожную карту" развития.

С другой стороны, тип требуемой базы данных может быть определен на основе множества различных факторов, включая среду, объем пользователя и доступное локальное оборудование, например, пространство на жестком диске.

.
12
ответ дан 23 November 2019 в 04:52
поделиться

Во-первых, разработчики должны понять, что есть что-то, что нужно знать о базах данных. Это не просто волшебные устройства, в которые вы помещаете SQL и получаете результирующие наборы, а очень сложные программные средства со своей логикой и причудами.

-вторых, что существуют разные настройки баз данных для разных целей. Вы не хотите, чтобы разработчик делал исторические отчеты из базы данных онлайн транзакций, если есть хранилище данных.

В-третьих, разработчики должны понимать основы SQL, в том числе присоединяться.

В прошлом это зависело от того, насколько тесно вовлечены разработчики. Я работал на рабочих местах, где был разработчиком и де-факто DBA, где DBA были только внизу, и где DBA работали в своей области. (Мне не нравится третья.) Предположим, что разработчики участвуют в проектировании баз данных:

Они должны понимать базовую нормализацию, по крайней мере, первые три нормальные формы. Что угодно, но только не это, получите DBA. Для тех, у кого есть опыт работы с залами судебных заседаний в США (а случайные телевизионные шоу здесь считаются), есть мнемоника "Зависит от ключа, от всего ключа", и ничего кроме ключа, так что помогите вам Codd."

Им нужна подсказка об индексах, под которой я подразумеваю, что они должны иметь некоторое представление о том, какие индексы им нужны и как они могут повлиять на производительность. Это значит не иметь бесполезных индексов, а не бояться добавлять их в помощь запросам. Все остальное (например, баланс) следует оставить для DBA.

Они должны понимать необходимость целостности данных и уметь указывать, где они проверяют данные и что они делают, если обнаруживают проблемы. Это не обязательно должно быть в БД (где будет трудно выдать пользователю значимое сообщение об ошибке), но должно быть где-то.

Они должны иметь базовые знания о том, как получить план, и как его вообще прочитать (по крайней мере, достаточно, чтобы понять, эффективны ли алгоритмы или нет).

Они должны смутно знать, что такое триггер, что такое представление, и что можно разбивать части БД на куски. Им не нужны никакие подробности, но они должны знать, чтобы спросить об этом у DBA.

Они, конечно, должны знать, что не надо вмешиваться в данные производства, или в код производства, или что-то подобное, и они должны знать, что весь исходный код идет в VCS.

Я, несомненно, кое-что забыл, но обычный разработчик не должен быть DBA, при условии, что есть реальная DBA.

.
22
ответ дан 23 November 2019 в 04:52
поделиться
[

]Для профессионального разработчика среднего уровня, который много пользуется базами данных (пишет/обслуживает запросы ежедневно или почти ежедневно), я думаю, что ожидание должно быть таким же, как и в любой другой области: [] Вы написали одну из них в колледже []. [

] [

] Каждый C++ гик написал в колледже класс строк. Каждый графический гик в колледже написал лучевой трекер. Каждый гик-веб написал интерактивные сайты (обычно до того, как у нас появились "веб-фреймворки") в колледже. Каждый аппаратный ботаник (и даже программный ботаник) строил в колледже процессор. Каждый врач препарировал целый труп в колледже, даже если она только собирается взять мое кровяное давление и сказать мне, что мой холестерин слишком высок сегодня. Почему базы данных должны быть другими?[

] [

] К сожалению, сегодня, по каким-то причинам, они выглядят по-другому. Люди хотят, чтобы .NET-программисты [] знали, как работают строки на C[], но внутренняя часть вашей СУБД [] не должна вас слишком беспокоить[].[

] [

] Практически невозможно получить такой же уровень понимания, просто читая о них, или даже работая сверху вниз. Но если вы начнете снизу и поймете каждую часть, то относительно легко разобраться в специфике вашей базы данных. Даже те вещи, которые многим ботаникам с базами данных не кажутся странными, например, когда использовать нестандартную базу данных.[

] [

]Может быть, это немного жестко, особенно, если вы не изучали информатику в колледже. Я немного смягчу: [] Ты можешь написать одну сегодня [], полностью, с нуля. Меня не волнует, знаете ли вы специфику работы PostgreSQL-оптимизатора запросов, но если вы знаете достаточно, чтобы написать его сами, то, скорее всего, он не будет слишком отличаться от того, что они делали. И знаете, написать базовую не так уж и сложно.[

]
3
ответ дан 23 November 2019 в 04:52
поделиться

Рассматривать денормализацию как возможного ангела, а не дьявола, а также рассматривать базы данных NoSQL как альтернативу реляционным базам данных.

Кроме того, я думаю, что модель Entity-Relation является обязательным знанием для каждого разработчика, даже если вы не проектируете базы данных. Она позволит вам полностью понять, что такое ваша база данных.

3
ответ дан 23 November 2019 в 04:52
поделиться

Отличный вопрос. Давайте посмотрим, сначала никто не должен рассмотреть вопрос о запросе DATBASE, которая не совсем понимает присоединения. Это похоже на вождение машины, не зная, где руль и тормоза. Вам также нужно знать DataTypes и как выбрать лучший.

Другое дело, что разработчики должны понимать, что есть три вещи, которые вы должны иметь в виду при разработке базы данных:

  1. целостность данных - если данные нельзя полагаться на вас, по существу, нет данных - это означает, что нет Поместите необходимую логику в приложении, так как многие другие источники могут коснуться базы данных. Ограничения, внешние ключей и иногда триггеры необходимы для целостности данных. Не используйте их, потому что вам они не нравятся, или не хочется их беспокоить.

  2. Производительность - очень трудно реформировать плохо выполнять базу данных и производительность следует учитывать с самого начала. Есть много способов сделать один и тот же запрос, и некоторые известны, как известно, почти всегда всегда, кратко видно, чтобы не учиться и использовать эти способы. Прочитайте некоторые книги по настройке производительности перед разработкой запросов или структур баз данных.

  3. Безопасность - эти данные - это жизненная кровь вашей компании, она также часто содержит личную информацию, которая может быть украдена. Научитесь защищать ваши данные от атак SQL-инъекции и мошенничества и кражи личных данных.

При запросе базы данных легко получить неправильный ответ. Убедитесь, что вы тщательно понимаете вашу модель данных. Помните часто фактические решения, основанные на основе данных вашего запроса возврата. Когда это неправильно, сделаны неправильные бизнес-решения. Вы можете убить компанию от вредных запросов или потерять большой клиент. Данные имеют значение, разработчики часто, кажется, забывают это.

Данные почти никогда не уходят, думают с точки зрения хранения данных со временем вместо того, как получить его сегодня. Эта база данных, которая работала нормально, когда у него было сто тысяч рекордов, может быть не так приятно через десять лет. Приложения редко бывают до тех пор, пока данные. Это одна из причин, по которой проектирование производительности имеет решающее значение.

Ваша база данных будет вероятно, нуждаются в полях, которые приложение не нужно видеть. Такие вещи, такие как GUID для репликации, дата вставленные поля. И т.д. Вам также может потребоваться хранить историю изменений и которые сделали их, когда и сможете восстановить плохие изменения из этого хранилища. Подумайте о том, как вы намереваетесь сделать это, прежде чем вы придете, спросите веб-сайту, как решить проблему, в которой вы забыли поставить предложение «Где» на обновлении и обновляли всю таблицу.

Никогда не развивайтесь в более новой версии базы данных, чем производственная версия. Никогда, никогда, никогда не развивайтесь непосредственно против производственной базы данных.

Если у вас нет администратора базы данных, убедитесь, что кто-то делает резервные копии и знает, как их восстановить и проверить их восстановление.

код базы данных является кодом, нет оправдания, чтобы не сохранить его в контроле источника, как и остальная часть вашего кода.

8
ответ дан 23 November 2019 в 04:52
поделиться

Я думаю, что каждый разработчик должен понимать, что базы данных требуют другая парадигма .

При написании запроса для получения ваших данных требуется установленный подход. Многие люди с взаимосвязью борьбы с этим. И все же, когда они обнимают его, они могут достичь гораздо лучших результатов, хотя решение может быть не тот, который впервые представил себя в своих итерационных сосредоточенных умах.

8
ответ дан 23 November 2019 в 04:52
поделиться

Порядок столбцов в неуникальном индексе важен.

Первый столбец должен быть столбцом с наиболее изменчивым содержанием (т. Е. Количеством элементов).

Это помогает SQL Server создавать полезные статистические данные о том, как использовать индекс во время выполнения.

2
ответ дан 23 November 2019 в 04:52
поделиться

Проблема несоответствия импеданса и знание общих недостатков ORM.

1
ответ дан 23 November 2019 в 04:52
поделиться

Совместимость с СУБД

Посмотрите, нужно ли запускать приложение более чем в одной СУБД. Если да, может потребоваться:

  • избегать расширений SQL СУБД
  • исключать триггеры и процедуры хранения
  • следовать строгим стандартам SQL
  • преобразовывать типы данных полей
  • изменять уровни изоляции транзакций

В противном случае, эти вопросы следует рассматривать отдельно, и будут разработаны различные версии (или конфигурации) приложения.

1
ответ дан 23 November 2019 в 04:52
поделиться

Простое уважение.

  • Это не просто репозиторий
  • Вы, вероятно, не знаете лучше, чем поставщик или администратор баз данных
  • Вы не будете поддерживать его в 3 часа ночи, когда на вас будут кричать старшие менеджеры
5
ответ дан 23 November 2019 в 04:52
поделиться

Не зависит от порядка строк, возвращаемых запросом SQL.

1
ответ дан 23 November 2019 в 04:52
поделиться

Поймите инструменты, которые вы используете для программирования базы данных!!!

Я потратил столько времени, пытаясь понять, почему мой код таинственным образом не работает.

Например, если вы используете .NET, вам нужно знать, как правильно использовать объекты в пространстве имен System.Data.SqlClient. Вы должны знать, как управлять объектами SqlConnection, чтобы убедиться, что они открываются, закрываются и, при необходимости, правильно утилизируются.

Вы должны знать, что при использовании SqlDataReader его необходимо закрывать отдельно от SqlConnection. Вы должны понимать, как держать соединения открытыми, когда это необходимо, чтобы минимизировать количество обращений к базе данных (поскольку они относительно дороги с точки зрения вычислительного времени).

2
ответ дан 23 November 2019 в 04:52
поделиться

Исходя из моего опыта работы с реляционными базами данных, каждый разработчик должен знать:

- Различные типы данных :

Использование правильного типа для правильной работы сделает вашу структуру БД более надежной, ваши запросы - быстрее и твоя жизнь проще.

- Узнайте о 1xM и MxM :

Это хлеб с маслом для реляционных баз данных. Вы должны понимать отношения «один ко многим» и «многие ко многим» и применять их тогда, когда это необходимо.

- Принцип « K.I.S.S. » также применим к БД :

Простота всегда работает лучше всего. Если вы изучили, как работает БД, вы избежите ненужных сложностей, которые приведут к проблемам с обслуживанием и скоростью.

- Индексы :

Недостаточно, если вы знаете, что они из себя представляют. Вы должны понимать, когда их использовать, а когда нет.


также:

  • Булева алгебра - ваш друг
  • Изображения: не храните их в БД. Не спрашивайте почему.
  • Протестируйте DELETE с помощью SELECT
5
ответ дан 23 November 2019 в 04:52
поделиться

Три (вещи) - это магическое число:

  1. Ваша база данных тоже нуждается в управлении версиями.

  2. Курсоры медленные и, вероятно, они вам не нужны.

  3. Триггеры - это зло*

*почти всегда

.
1
ответ дан 23 November 2019 в 04:52
поделиться
Другие вопросы по тегам:

Похожие вопросы: