Ответ 1

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

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

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

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

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

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

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

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

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

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

Уф!

Ответ 2

• Нормализация, по крайней мере, для второй нормальной формы, необходима.

• Ссылочная целостность также важна при правильных каскадных процедурах удаления и обновления.

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

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

• Определите последовательный подход для первичных ключей и кластеризованных ключей.

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

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

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

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

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

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

Отказ

Аргументы заимствованы из preface моей бесплатной книги " Используйте Индекс, Люк". Я трачу довольно много времени, объясняя, как работают индексы и как их правильно использовать.

Ответ 7

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

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

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

Ответ 8

Избегайте SQL инъекция и как защитить ваша база данных

Ответ 9

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

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

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

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

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

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

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

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

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

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

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

Ответ 12

Эволюционная конструкция базы данных. http://martinfowler.com/articles/evodb.html

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

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

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

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

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

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

Ответ 16

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

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

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

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

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

- K.I.S.S." применим также к БД:

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

- Индексы:

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

и

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

Ответ 17

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

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

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

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

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

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

Ответ 18

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

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

Ответ 19

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

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

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

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

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

Ответ 20

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

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

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

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

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

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

Ответ 21

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

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

Ответ 22

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

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

Ответ 23

• Основные навыки SQL.
• Indexing.
• Поделитесь с различными воплощениями DATE/TIME/TIMESTAMP.
• Документация JDBC для используемой платформы.
• Работа с двоичными типами данных (CLOB, BLOB и т.д.)

Ответ 24

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

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

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

Ответ 25

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

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

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

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

Ответ 26

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

• Для вашей базы данных также требуется управление версиями.

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

• Триггеры злы *

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

Ответ 27

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

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

Ответ 28

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

Ответ 29

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

Посмотрите, требуется ли это для запуска приложения в нескольких RDBMS. Если да, может потребоваться:

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

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

Ответ 30

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