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

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

Руководство по ответам:

Держите свой список коротким.
Лучше всего одна концепция на ответ.

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

Объясните свое обоснование.
Почему ваша концепция важна? Не просто говорите «используйте индексы». Не впадайте в «лучшие практики». Убедите свою аудиторию пойти и узнать больше.

Upvote ответы, с которыми вы согласны.
Сначала прочитайте ответы других людей. Один высокопоставленный ответ - более эффективное утверждение, чем два высокопоставленных. Если у вас есть что добавить, либо добавьте комментарий, либо сделайте ссылку на оригинал.

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

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

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

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

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

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

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

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

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

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

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

Уф!

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

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

2. Ссылочная целостность также важна с учетом каскадного удаления и обновления.

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

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

5. Выберите согласованный подход для первичных ключей и кластерных ключей.

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

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

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

9. Не увлекайся триггерами. У них есть свое применение, но они могут все усложнить в спешке.

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

11. Получить книгу Селко по дизайну базы данных. Человек высокомерен, но знает свое дело.

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

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

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

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

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

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

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

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

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

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

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

Основное индексирование

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

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

Дизайнеры также должны знать об общих анти-шаблонах индекса, например:

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

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

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

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

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

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

Как работают индексы

Это, наверное, не самая важная, но наверняка самая недооцененная тема.

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

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

Это связано с тем, что базы данных SQL отлично работают, работая как черный ящик:

Скажите мне, что вам нужно (дай мне SQL), я позабочусь об этом.

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

Именно тогда индексация становится темой. Но обычно это очень поздно, и кто-то (какая-то компания?) Уже страдает от реальной проблемы.

Вот почему я считаю, что индексирование - это тема № 1, которую нельзя забывать при работе с базами данных . К сожалению, это очень легко забыть.

отказ

Аргументы заимствованы из предисловия моей бесплатной электронной книги " Use The Index, Luke ". Я трачу довольно много времени на объяснение того, как работают индексы и как их правильно использовать.

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

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

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

Как избежать SQL- инъекций и как защитить вашу базу данных

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

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

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

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

Кроме того, следствие: больше индексов не лучше.

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

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

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

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

Еще одна вещь, которую разработчики должны понять, это то, что вы должны иметь в виду три вещи при проектировании базы данных:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- разные типы данных :

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

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

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

- Принцип « KISS » распространяется и на БД :

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

- индексы :

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

также:

• Булева алгебра твой друг
• Изображения: не храните их в БД. Не спрашивай почему.
• Тест DELETE с помощью SELECT

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

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

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

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

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

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

Каждый разработчик базы данных должен знать, что «реляционный» не равен «SQL». Тогда они поймут, почему поставщики СУБД так отчаянно разочарованы, и почему они должны говорить тем же поставщикам, что они должны придумать более качественные вещи (например, СУБД, которые действительно являются реляционными), если они хотят продолжать сосать веселые суммы деньги своих клиентов за такое дерьмовое программное обеспечение).

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

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

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

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

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

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

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

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

Никогда не вставляйте данные с неправильной кодировкой текста.

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

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

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

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

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

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

Знайте свой процесс выполнения базы данных и планируйте его.

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

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

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

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

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

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

Первый столбец должен быть столбцом, который имеет наибольшую вариативность по своему содержанию (то есть количество элементов).

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

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

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

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

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

• Базовые навыки SQL.
• Индексирование.
• Разобраться с различными воплощениями ДАТА / ВРЕМЯ / ВРЕМЯ.
• Драйвер JDBCДокументация для используемой вами платформы.
• Работа с двоичными типами данных ( CLOB , BLOB и т. Д.)

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

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

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

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

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

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

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

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

http://www.reddit.com/r/programming/comments/azdd7/programmers_sit_your_butt_down_i_need_to_have_a/