Что важнее? БД дизайн или кодирование?
Что важнее: дизайн базы данных? Или дизайн кода приложения?
Существует много информации о коде многократного использования (от Карла Франклина на http://dnrtv.com/, CSLA.net и др.), Но я не вижу слишком много информации о дизайне баз данных и его влиянии на жизнь приложения (особенно то, как плохие дизайнерские решения рано влияют на приложение позже в его "жизни".
36 ответов
Как правило, структура базы данных является более важной, поскольку она обеспечивает структурную основу, на которой разрабатывается ваш код. В целом (и YMMV довольно значительно), рефакторинг структуры вашей БД после завершения фазы разработки значительно сложнее, чем просто рефакторинг кода, который зависит от стабильной базы данных. Причина проста; рефакторинг структуры вашей БД обычно вызывает изменения кода; обратное редко бывает правдой.
Проще говоря, ваш код зависит от вашей базы данных больше, чем ваша база данных зависит от вашего кода. (Если это не так, возможно, вам придется пересмотреть свой дизайн.)
Обратиться к вашему редактированию; Я думаю, что многие люди, пишущие / пишущие на блоге об этом типе проблемы, имеют тенденцию довольно сильно исходить со стороны "кодирования", эти типы людей склонны считать дизайн базы данных тривиальным и менее интересным, чем кодирование интересных решений. По сути, для тех, кто любит решать "хитрые проблемы" (а это чаще всего люди, которые больше пишут в блогах), сторона программирования более интересна, чем фундаментальные проблемы дизайна. И хотя фундаментальные проблемы дизайна не "сексуальны", они чрезвычайно важны (а дизайн баз данных - ОЧЕНЬ фундаментальная проблема дизайна).
Краткий ответ: оба. Цепь так же сильна, как и самое слабое звено.
Ваш дизайн БД является наиболее важным.
Я кодер, и я предпочитаю код, но... если вы испортите дизайн БД, ваш код станет кошмаром. У вашего кода не будет шансов!
Даже если вы попытаетесь изменить структуру БД, у вас будет так много работы с кодом, что исправление всего этого будет огромным.
Это не является предпочтением или даже близким, оно очень сильно склоняется к тому, чтобы дизайн БД был наиболее важным.
РЕДАКТИРОВАТЬ: Даже если бы у вас были таблицы пар ключ-значение, в которые все было добавлено, это все равно было бы дизайном БД, основанным на бизнес-требованиях.
Перефразируя Кнута -
Гораздо важнее использовать эффективную структуру данных. Плохая структура замедлит ваше приложение независимо от вашего алгоритма, а хорошая структура может даже устранить необходимость в определенных алгоритмах.
Я думаю, что это в равной степени относится к БД. В конечном итоге вы создаете массивно связанную структуру данных. Если вы не используете правильные методы, ваше приложение будет работать медленно, независимо от того, сколько хитрости вы в него вложите.
Рассмотрим этот вариант
- Изменение кода означает изменение кода
- Изменение базы данных, вероятно, также заставит вас изменить код
Поэтому важно сделать базу данных как можно более стабильной как можно раньше
Прежде чем поработать с ужасным дизайном базы данных, я должен положить свою шляпу в кольцо дизайна базы данных (или модели данных / ORM).
Соберитесь с людьми, хорошо осведомленными в вашей компании / клиенте о проблемной области, и получите все необходимые данные на бумаге, сгруппируйте их по логическим областям, и вы начнете формировать модель данных, которую вы можете превратить в Объекты, Схемы базы данных. или.xsd и т. д. Каждый элемент данных будет иметь имя, тип, может быть максимальную длину для строк, или будет набором, списком или картой определенных минимальных или максимальных мощностей.
Независимо от того, разрабатываете ли вы базу данных сначала после этого, или модель ОО зависит от вас, но, по крайней мере, вы постарались получить разумную многораздельную модель заранее.
Фактически в проекте MVC я бы классифицировал модель данных ОО (классы в Java/C#) как модель, которая неразрывно связана со схемой базы данных (с добавленными переходными процессами и вспомогательными методами, конечно). Ваш контроллер - "кодирование" в вашем вопросе - должно действительно реализовывать бизнес-логику с использованием модели, представленной объектами, которые вы извлекаете из базы данных через DAO/ORM.
Модель предметной области не должна зависеть от деталей реализации постоянства (хотя технология накладывает некоторые ограничения на модель) - http://www.infoq.com/articles/ddd-in-practice
Вы должны сосредоточиться на модели предметной области. С помощью великолепной технологии ORM, такой как Hibernate / NHibernate, база данных будет лишь деталью реализации.
Книги, которые вы должны прочитать, если вы занимаетесь веб-разработкой.NET:
- ASP.NET MVC Framework Preview (всего 100 страниц, и вы начнете)
- NHibernate в действии
- Доменное проектирование и разработка на практике (не читайте, но я буду, и это бесплатно)
- Рефакторинг: улучшение дизайна существующего кода
Ни то, ни другое не важно, но...
Плохой дизайн базы данных может сделать невозможным написание хороших программ. Кроме того, обычно вы можете переписать плохой код, но если у вас много данных в базе данных, вам просто придется принять неверные решения, принятые на этапе проектирования.
По моему опыту (и около 30 лет я занимался исправлением проблем с базами данных и имел дело с сотнями различных баз данных), что слишком много проблем в производительности баз данных связано с неуместными попытками повторного использования кода. Функции намного медленнее, чем встроенный код. Курсоры, повторно использующие хранимый процесс, который вставляет одну запись за раз, намного, намного, намного (световые годы) медленнее, чем код на основе набора. Повторное использование процедуры, которая возвращает то, что вам нужно, и десять других полей неэффективно расходуют ресурсы сервера и сети. Использование существующего представления, объединяющего десять таблиц, когда вам нужна информация только из трех из них, приводит к неэффективному использованию ресурсов сервера. Повторное использование кода в базах данных не так хорошо, как в других местах. Это не означает, что код не должен использоваться повторно, если это необходимо. Просто это никогда не должно иметь приоритет над производительностью. К сожалению, базы данных плохо спроектированы для повторного использования кода. Большинство баз данных не являются объектно-ориентированными, и объектно-ориентированное мышление при разработке или доступе к ним часто приводит к плохому дизайну.
Прежде чем вы сможете подумать о повторном использовании кода, вы должны иметь надежную нормализованную структуру базы данных. Вам нужно подумать о том, как вы будете извлекать, а также вставлять данные в базу данных. Вам нужно подумать о том, насколько хорошо это будет работать, если будет много пользователей и записей, потому что на этом этапе перестройка базовой структуры базы данных часто становится слишком дорогой и отнимает много времени. Зачастую рефакторинг кода приложения намного проще, чем базовой структуры базы данных, и слишком часто рефакторинг базы данных не выполняется. Если вы измените структуру таблицы, чтобы перейти от денормализованной таблицы к родительской дочерней структуре, потому что вы обнаружите, что текущая структура не соответствует вашим потребностям, вы можете в конечном итоге изменить сотни или даже тысячи запросов к этой таблице. Вот почему важно тратить много времени на разработку базы данных, у вас не будет возможности вернуться к ней позже из-за нехватки времени / денег. Если вы рассматриваете базу данных как основу дома, а код приложения - как структуру, вы поймете, почему это так. Намного сложнее изменить фундамент со структурой на нем, чем сдвинуть внутренние стены. Базы данных и приложения, которые обращаются к ним одинаково.
В каком-то смысле вы не можете разделить их: дизайн БД - это кодирование, а не кодирование на процедурном языке.
Однако я работал с системами, которые имели плохо разработанное процедурное программное обеспечение, и я работал с системами, которые имели плохо разработанные схемы баз данных (схемы?). По моему опыту, исправить схемы гораздо сложнее из-за проблем с обновлением и совместимостью. Я могу представить себе системы, в которых это не могло быть так.
Я не думаю, что вы можете разделить их так, как вы описываете. Одно неизменно будет влиять на другого. Например, надежная структура базы данных, которую легко поддерживать и которая работает хорошо, будет означать меньшее количество изменений кода. Хорошо спроектированный код и четкое понимание ваших сценариев использования приведут к аккуратной и поддерживаемой схеме базы данных.
За свои деньги я бы потратил больше на прочный бизнес-уровень и создал бы свою базу данных для его поддержки, но это моя предубежденность в отношении знаний.
Я вижу, что буду плыть вверх по течению, но я довольно сильно склонен к тому, чтобы программное обеспечение было ответом на ваш вопрос.
Хотя ваше программное обеспечение может адаптироваться к слабой схеме, ваша база данных мало чем может помочь, если ваше программное обеспечение не работает. У меня была пара случаев, когда я мог взять популярное интерфейсное приложение и полностью перестроить базу данных без серьезных сбоев, потому что пользователи не видят базу данных напрямую. (Что не будет правдой, если программное обеспечение дерьмо.)
Поэтому я бы сказал, обратите внимание на то, что ближе всего к пользователю в первую очередь.
Я не буду пытаться дублировать многие прекрасные комментарии, сделанные до сих пор. Я также не буду тратить время на выявление сомнительных заявлений, также сделанных.
Но я добавлю следующие пункты.
Если вы похожи на большинство людей, вы обращаетесь к СУБД в качестве базы данных в своем вопросе. СУБД по сути является рабом. Он прослушивает порт и обязан пытаться обслуживать все запросы, поступающие через этот порт. Он не знает, какие из этих запросов просто глупы или опрометчивы. Таким образом, наиболее идеально сконструированная БД легко подвергается злоупотреблению вплоть до блокировки сервера. Это означает, что код важнее. Повсюду можно встретить администраторов баз данных, выдергивающих свои волосы в ответ на некоторые глупые вещи, которые разработчики приложений бросают на серверы, которыми они управляют.
Поэтому лучший совет, который я могу дать вам по этой теме, - обеспечить доступ к БД через API, написанный тем же разработчиком, который разработал БД. Возьмите на себя ответственность одного чувака (или одной группы, подотчетной одному и тому же чуваку), чтобы обеспечить принятие обоснованных проектных решений для обоих. Если ты такой чувак, то не экономь на одном за счет другого. Разработайте свой API так, чтобы рефакторинг БД можно было сделать прозрачно для клиентов API.
Зависит от того, где вы знаете как..., так и требования к продукту.
Пренебрежение любой стороной, и ваш продукт может быть в беде.
Тем не менее, я склонен следовать DDD-стилю кодирования, где я сначала определяю все, кроме своей базы данных. Это дает мне лучшее представление о том, какие данные необходимо хранить.
Затем, как только это будет завершено, я могу создать и настроить свою базу данных для набора.
Я согласен, что оба критически важны, но есть существенные методы, которые вы можете использовать на уровне представления, функции, хранимой процедуры, чтобы компенсировать довольно ужасные ошибки базовой схемы. С другой стороны, если у вас плохое кодирование, если, конечно, его не исправить, на уровне разработки вы не сможете многое сделать, чтобы это исправить.
Они не являются взаимоисключающими. Оба должны быть твердыми, чтобы иметь возможность найти твердое решение.
Если вы не уверены в своих навыках в какой-либо области, сделайте все возможное, чтобы разделить их как можно больше. Худший сценарий - написание запутанного беспорядка, который не может быть легко исправлен или поддержан позже.
Мы переписывали сайт 3 раза за 4 года. база данных не изменилась. (ну немного)
Это зависит от того, что важно для вашего бизнеса. В идеале, вы также не должны менять шорт, но если вы должны, вы должны также задать себе этот вопрос:
Есть ли ваше приложение для обработки данных или данные выходят за пределы вашего приложения?
Другими словами, если часть кода вашего приложения взорвалась сегодня, но ваши данные все еще там, насколько страшной была бы катастрофа? Если вы ответите:
Я всегда могу написать код для замены приложения, но без данных мы обречены.
Тогда вам лучше убедиться, что ваши данные в порядке, потому что они, вероятно, переживут любой код, который вы пишете сегодня. Это не значит, что вы не должны прилагать больших усилий для написания надежной базы кода, но код, в конечном счете, временный, тогда как ваши данные - нет. Если вы застряли с плохим кодом, вы можете переписать его, но если у вас плохие данные, это, вероятно, будет иметь более широкие последствия.
С другой стороны, если данные действительно существуют только для того, чтобы убедиться, что ваш код работает хорошо, а сам код более важен (обратный сценарий выше), вы должны убедиться, что у вас есть хорошая кодовая база, и вернуться к любой недостатки в данных позже.
РЕДАКТИРОВАТЬ
В большинстве корпоративных приложений данные гораздо важнее. В прошлом я работал над проектами преобразования, где код был далеко позади, но миграция была отложена на очень долгое время (иногда десятилетия), потому что данные были настолько плохими, что потребовались значительные и очень дискреционные усилия, чтобы получить данные для точка здоровья, куда это могло быть перенесено.
И то и другое
Отличный код может быть разрушен ужасным дизайном БД, а отличный дизайн - разрушенным ужасным кодом.
Оба важны, конечно, это симбиотические отношения.
Но если ваша БД повреждена, никакое количество хорошего кода не может заставить ваше приложение сиять.
Однако, если ваша БД действительно хороша, то хороший код может сделать ее еще лучше (но плохой код все еще может ее испортить).
Это важно делать точно и профессионально. Чтобы избежать будущих головных болей, сделайте это правильно сейчас, так как изменения, исправления или улучшения намного сложнее, когда все находится в камне.
Это зависит от вашей точки зрения. Если вы администратор базы данных, то БД, если вы разработчик, чем код.
Я видел, как разработчики полностью злоупотребляли базой данных с помощью "мешочных" таблиц, и я видел, как администраторы баз данных создают чудовищный код приложения, что хорошо, если вы понимаете структуру базы данных, но непрозрачны в противном случае.
Следовательно, оба критически важны, и если у вас есть опыт только в одном, вы должны заставить кого-то опытного посмотреть на другого или улучшить свой собственный набор навыков там, где его не хватает.
Это ошибочное мнение, что данные принципиально отличаются от исполняемого кода. Теория клеточных автоматов полна примеров, когда данные и код сильно "запутаны".
Но, поскольку выбранный BD менее легко модифицируем, вам следует обратить внимание на глобальную архитектуру. Но если вы не уверены в окончательном варианте, вам следует приложить максимум усилий, чтобы подумать о самой легко расходуемой архитектуре BD.
Мой опыт показывает, что изменить код легче, чем BD.
Понимание предметной области является наиболее важным. Вы должны понимать, что вы хотите сделать со своим приложением. Из понимания предметной области вам необходимо понять, какую информацию вы планируете хранить, а также отношения между информационными единицами. Вы также должны понимать варианты использования.
После этого дизайн базы данных является наиболее важным. База данных - это лучшее место для систематизации информации, полученной в результате анализа вашего домена. Как только у вас есть необходимые данные, вы должны максимально нормализовать данные. Затем вы должны понять диапазон допустимых значений для каждого поля и написать процедуры проверки данных для каждого (в форме проверочных ограничений, хранимых процедур, регулярных выражений или чего-либо еще, что имеет смысл).
Я обнаружил, что чаще всего, когда ваши данные сильно нормализуются, объем кода, необходимый для завершения вашего приложения, значительно падает по нескольким причинам:
- Вы не пишете код для поиска, сортировки, индексации, объединения и группировки данных. SQL делает это для вас.
- Нормализованные данные не дублируются. Это означает, что каждое обновление происходит в одном и только одном месте. Если вам нужно написать код для синхронизации данных во многих местах, код становится раздутым и подверженным ошибкам.
- Вам не нужно писать столько кода для обработки ошибок, потому что большая его часть находится в вашем коде проверки данных.
- Когда объем вашего кода падает, вам нужно меньше разработчиков, чтобы поддерживать код. Это означает, что модули, принадлежащие разным людям, с меньшей вероятностью отклонятся от общего замысла программы.
Код по-прежнему важен, но теперь вам нужно написать его намного меньше.
И то, и другое важно, но плохой дизайн любого из вышеперечисленных видов деятельности, как правило, труднее исправить. Например, изменения функциональных спецификаций, естественно, вызовут гораздо больше работы, чем некоторые словесные изменения в интерфейсе.
Любые значимые изменения в базе данных, как правило, также требуют изменений в кодировании, поэтому я лично трачу больше времени на агонию за решения по проектированию базы данных, чем за решениями по кодированию (хотя я уверен, что я не единственный, кто потратил час или два попытки найти идеальное имя для класса).
ИМХО Хороший дизайн базы данных важнее хорошего кодирования (хорошее кодирование также важно, но сравните с дизайном базы данных).
- Просто потому, что база данных будет хранить ваши ценные данные.
- Плохое кодирование может не повлиять на базу данных, но повлияет на масштабируемость, производительность всего приложения и т. Д. В течение определенного периода времени это можно исправить путем рефакторинга (конечно, с некоторыми затратами).
- Рефакторинг базы данных намного дороже и сложнее.
- Также обычно у нас есть несколько разных приложений, работающих на одной базе данных, так что это общий фактор.
"Приложения являются временными, но данные являются постоянными"
для меня ДБ дизайн более важен, это основа приложения, которое вы собираетесь кодировать.
Я не могу сказать, что дизайн базы данных важнее, чем дизайн кода, но, по крайней мере, он такой же. Если вы написали отличный код, но ваша БД плохая, то у вашего приложения будут проблемы с производительностью, и наоборот.
Что касается дизайна БД, то здесь много материалов (в том числе книг). Посмотрите на предмет нормализации базы данных