Что важнее: дизайн базы данных? Или дизайн кода приложения?
Существует много информации о многократном использовании кода (от Карла Франклина в dnrtv.com, CSLA.net, et al.), но я не вижу слишком много информации о дизайне базы данных и ее влиянии на жизнь приложения (особенно, как плохие дизайнерские решения рано повлиять на приложение позже в его "жизни".
В целом структура базы данных важнее, поскольку она обеспечивает структурную структуру, на которой разрабатывается ваш код. В целом (и YMMV довольно значительно) реорганизация структуры БД после завершения фазы разработки значительно сложнее, чем просто рефакторинг кода, который зависит от стабильной базы данных. Причина проста; реорганизация структуры БД обычно приводит к изменениям кода; реверс редко бывает прав.
Проще говоря, ваш код зависит от вашей базы данных больше, чем ваша база данных зависит от вашего кода. (Если это не так, вам может потребоваться переосмыслить ваш дизайн.)
Чтобы обратиться к редактированию; Я думаю, что многие люди, пишущие/занимающиеся блогом об этом типе проблем, как правило, довольно сильно исходят из "кодирующей" стороны вещей, эти типы людей склонны считать дизайн базы данных тривиальным и менее интересным, чем кодирование интересных решений. По сути, кому-то, кто любит решать "сложные проблемы" (которые, как правило, люди, которые больше занимаются блогами), кодирующая сторона более интересна, чем фундаментальные проблемы дизайна. И хотя основные проблемы дизайна не являются "сексуальными", они чрезвычайно важны (и дизайн базы данных - ОЧЕНЬ фундаментальная проблема дизайна).
Короткий ответ: оба. Цепь столь же сильна, как и самое слабое звено.
Если вы небрежны с тем, кого вы обречены.
Дизайн БД наиболее важен.
Я кодер, и я предпочитаю код, но... если вы испортите дизайн БД, ваш код станет кошмаром. У вашего кода не будет возможности!
Даже когда вы пытаетесь реорганизовать проект БД, у вас будет так много работы над кодом, что его исправление будет огромным.
Это не предпочтение или даже близкое, оно очень сильно зависит от дизайна БД.
EDIT: даже если у вас должны быть парные таблицы с ключом, где все в него попало, это все равно будет дизайн БД, основанный на бизнес-требованиях.
Перефразируя Кнут -
Гораздо важнее использовать эффективная структура данных. Плохой структура замедлит ваш независимо от вашего алгоритм и хорошая структура могут даже устранить необходимость определенных алгоритмы.
Я думаю, что это в равной степени относится к БД. В конечном итоге вы создаете массивную структуру данных. Если вы не используете правильные методы, ваше приложение будет медленным, независимо от того, насколько вы обманываете его.
Прежде чем работать с ужасающим дизайном базы данных, я должен поместить свою шляпу в кольцо создания базы данных (или модели данных /ORM ).
Соберитесь вместе с некоторыми людьми, осведомленными в вашей компании/клиенте о проблемной области, и получите все данные, необходимые на бумаге, группа по логическим областям, затем вы начнете формировать модель данных, в которой вы могли бы превратиться в объекты, Схемы базы данных или .xsd и т.д. Каждый элемент данных будет иметь имя, тип, возможно максимальную длину для строк, или быть набором или списком или картой определенных минимальных или максимальных емкостей.
Создайте ли вы базу данных сначала после этого, или модель OO зависит от вас, но, по крайней мере, вы сделали попытку получить стандартную разделенную модель спереди.
На самом деле в MVC-дизайне я бы классифицировал модель данных OO (классы в Java/С#) в качестве модели и по существу связанную с схемой базы данных (с добавленными переходными процессами и полезными методами, конечно). Ваш контроллер - "кодирование" в вашем вопросе - должен действительно реализовывать бизнес-логику с использованием модели, представленной объектами, которые вы извлекаете из базы данных через DAO/ORM.
Посмотрите на это таким образом
Ergo важно как можно скорее получить базу данных как можно более стабильную
Модель домена должна быть независимой от деталей реализации непрерывности (хотя технология действительно создает некоторые ограничения для модели) — http://www.infoq.com/articles/ddd-in-practice
Вы должны сосредоточиться на модели домена. С отличной технологией ORM, например Hibernate/NHibernate база данных будет только деталью реализации.
Книги, которые вы должны прочитать, если вы занимаетесь разработкой .NET:
Это был мой опыт (и я занимался исправлением проблем с базой данных около 30 лет и имел дело с сотнями различных баз данных), что слишком многие проблемы производительности базы данных связаны с ненадлежащими попытками повторного использования кода, Функции намного медленнее, чем встроенный код. Курсоры, повторно использующие хранимую процедуру, которая вставляет одну запись за раз, далеки, далеко, далеко (светлые годы) медленнее, чем код на основе набора. Повторное использование proc, которое возвращает вам то, что вам нужно, и еще десять полей являются расточительными для серверных и сетевых ресурсов. Использование существующего представления, которое объединяется в десять таблиц, когда вам нужна только информация из трех из них, является расточительным для ресурсов сервера. Повторное использование кода в базах данных не так хорошо, как в других местах. Это не означает, что код не должен использоваться повторно при необходимости. Просто, чтобы он никогда не превалировал над производительностью. К сожалению, базы данных не предназначены для повторного использования кода. Большинство баз данных не являются объектно-ориентированными, а объектно-ориентированное мышление при проектировании или доступе к ним часто приводит к плохому дизайну.
Прежде чем вы сможете даже подумать о повторном использовании кода, вам необходимо иметь нормальный нормализованный дизайн базы данных. Вам нужно подумать о том, как вы будете извлекать, а также вставлять данные в базу данных. Вам нужно подумать о том, насколько хорошо это будет работать после того, как будет много пользователей и записей, потому что перестройка базовой структуры базы данных в этот момент часто становится слишком дорогостоящей и требует много времени. Часто гораздо проще реорганизовать код приложения, чем базовую структуру базы данных, и слишком часто рефакторинг базы данных не выполняется. Если вы измените структуру таблицы, чтобы перейти от денормализованной таблицы к родительской дочерней структуре, потому что вы обнаружите, что текущая структура не соответствует вашим потребностям, тогда вы можете в итоге изменить сотни или даже тысячи запросов к этой таблице. Вот почему очень важно потратить много времени на разработку базы данных, вы не получите возможность вернуться к ней позже из-за ограничений времени и денег. Если вы считаете, что база данных является основой дома и код приложения как структуры, вы увидите, почему это так. Намного сложнее изменить фундамент со структурой сверху, чем перемещать внутренние стены. Базы данных и приложения, которые обращаются к ним, одинаковы.
Также неважно, но...
Плохая конструкция базы данных может затруднить запись хороших программ. Кроме того, вы можете обычно переписывать плохой код, но если у вас много данных в базе данных, вам просто нужно жить с плохими решениями, принятыми на этапе проектирования.
Я не думаю, что вы можете разделить их так, как вы описываете. Одно будет неизменно влиять на другое. Например, надежный дизайн базы данных, который легко поддерживать и выполняет хорошо, будет означать меньшее количество изменений кода. Хорошо продуманный код и сильное понимание ваших прецедентов приведут к аккуратной и поддерживаемой схеме базы данных.
За свои деньги я бы потратил больше на прочном бизнес-слое и построил свою базу данных, чтобы поддержать его, но это моя предвзятость.
В некотором смысле, вы не можете отделить два: дизайн БД - это кодирование - это просто не кодирование на процедурном языке.
Однако я работал с системами с плохо разработанным программным программным обеспечением, и я работал с системами с плохо разработанными схемами базы данных (схемы?). По моему опыту, исправление схем намного сложнее из-за проблем с обновлением и совместимостью. Я могу представить системы, где это могло бы быть не так.
Я вижу, что буду плавать вверх по течению, но я довольно сильно склонен к тому, что программное обеспечение является ответом на ваш вопрос.
В то время как ваше программное обеспечение может адаптироваться к слабой схеме, вам не поможет ваша база данных, если ваше программное обеспечение дисфункционально. У меня было несколько случаев, когда я смог использовать популярное внешнее приложение и полностью перестроить базу данных без серьезных сбоев, потому что пользователи не видят базу данных напрямую. (Это неправда, если программное обеспечение - это дерьмо.)
Итак, я бы сказал, обратите внимание на то, что ближе всего к пользователю.
Я не буду пытаться дублировать многие замечательные комментарии, сделанные до сих пор. Я также не буду тратить время на выявление сомнительных заявлений.
Но я добавлю следующие моменты.
Если вы похожи на большинство людей, вы ссылаетесь на СУБД как базу данных в своем вопросе. СУБД по существу является подчиненным. Он слушает порт и обязан выполнять все запросы, поступающие через этот порт. Он не знает, какие из этих просьб просто глупы или необоснованны. Таким образом, для максимально совершенной БД легко злоупотреблять до момента блокировки сервера. Это означает, что код более важен. Администраторы баз данных повсюду можно найти, вытаскивая свои волосы в ответ на некоторые из тупых вещей, которые разработчики приложений бросают на серверы, которыми они управляют.
Поэтому лучшим советом, который я могу дать вам по этой теме, является обеспечение доступа к БД с помощью API, написанного тем же разработчиком, который разработал БД. Сделать ответственность за одного чувака (или одну группу от одного и того же чувака), чтобы обеспечить принятие обоснованных решений по дизайну для обоих. Если вы этот чувак, то не экономьте на одном за счет другого. Создайте свой API так, чтобы рефакторинг БД можно было сделать прозрачно для клиентов API.
Зависит от того, где вы знаете, как..., так и требования к продукту.
Отбросьте обе стороны, и ваш продукт может быть в затруднении.
Тем не менее, я, как правило, придерживаюсь стиля кодирования DDD, где сначала определяю все, кроме моей базы данных. Это дает мне лучшее представление о том, какие данные необходимо хранить.
Затем, как только это будет завершено, я могу создать и настроить мою базу данных в Suite.
Дизайн, если вы DBM.
Кодирование, если вы программист.
Они не являются взаимоисключающими и должны быть хорошо выполнены.
И
Отличный код может быть разрушен ужасным дизайном db, а отличный дизайн db может быть разрушен ужасным кодом.
Они не являются взаимоисключающими. Оба должны быть твердыми камнями, чтобы иметь шанс на твердотельный раствор.
Я согласен, что оба являются критическими, но существуют существенные методы, которые вы можете использовать на уровне представления, функции, уровня хранимых процедур, чтобы компенсировать довольно ужасные ошибки схемы. С другой стороны, если ваше кодирование плохое, не исправляя его, конечно, не так много можно сделать на уровне разработки, чтобы исправить это.
Если вы не уверены в своих навыках в любой из областей, сделайте все возможное, чтобы разделить их как можно больше. Худший сценарий - это путаница, которая не может быть легко исправлена или сохранена позже.
Это зависит от того, что важно для вашего бизнеса. В идеале, вы также не должны делать короткие изменения, но если вам нужно, вы также должны задать себе этот вопрос:
Используется ли ваше приложение для обработки данных или данные превосходят ваше приложение?
Другими словами, если бы часть кода вашего приложения взорвалась сегодня, но ваши данные все еще существуют, насколько плохой будет катастрофа? Если вы отвечаете:
Я всегда могу написать код для замены приложения, но без данных мы обречены.
Тогда вам лучше убедиться, что ваши данные звучат, потому что он, вероятно, переживет любой код, который вы пишете сегодня. Это не означает, что вы не должны прикладывать большие усилия для написания надежной кодовой базы, но код в конечном счете является переходным, тогда как ваши данные не являются. Если вы застряли с плохим кодом, вы можете переписать, но если у вас плохие данные, это, скорее всего, будет иметь гораздо более широкие последствия.
С другой стороны, если данные действительно существуют только для того, чтобы убедиться, что ваш код работает хорошо, а сам код более важен (обратный вышеприведенный сценарий), вы должны убедиться, что у вас хорошая кодовая база, и позже просмотрите все недостатки в данных.
ИЗМЕНИТЬ
В большинстве корпоративных приложений данные гораздо важнее. Я работал над конверсионными проектами в прошлом, когда код был далеко за его жизнь, но миграция задерживалась так долго (иногда десятилетия), потому что данные были настолько плохими, что потребовались значительные и очень дискреционные усилия, чтобы получить данные на где его можно было мигрировать.
Оба важны, конечно, это симбиотические отношения.
Но если ваша БД выгружена, никакое количество хорошего кода не может заставить ваше приложение сиять.
Однако, если ваша БД действительно хороша, тогда хороший код может сделать ее еще лучше (но плохой код все еще может ее испортить).
мы переписывали сайт 3 раза в 4 года. база данных не изменилась. (ну, немного)
Оба являются лишь частью реализации того, на что, конечно же, вы тратите основную часть своего времени - требования и дизайн.
Возможно, я не очень разбираюсь в дизайне базы данных, но я чувствую: если ваши бизнес-классы хорошо разработаны, единственная точка, к которой вы обращаетесь к базе данных, находится в ваших репозиториях (DDD-речь).
Таким образом, изменение базы данных - это просто изменение в реализации вашего репозитория. Плохой дизайн базы данных сделает ваш репозиторий трудным для кодирования и медленного выполнения, но он не повлияет на ваш бизнес-уровень (90% вашего кода).
Если вы пытаетесь изменить свой бизнес-уровень из-за своего уровня DAO, почему бы не изменить свой бизнес-уровень из-за вашего уровня представления? а затем удачи удовлетворить все ограничения и хорошие практики!
Я думаю, что оба они важны, но кодирование и дизайн базы данных не должны быть в одних руках. Тем более важно, чтобы разработчик изолировал себя от работы дизайнера db. (Даже если разработчик Db и разработчик являются одним и тем же человеком, вам не нужно думать о двух вещах одновременно)
Это зависит от вашей перспективы. Если вы DBA, то db, если вы разработчик, чем код.
Я видел, что разработчики полностью злоупотребляют базой данных таблицами "сумка", и я видел, как администраторы баз данных создают чудовищный код приложения, который хорош, если вы понимаете структуру базы данных, но непрозрачную в противном случае.
Эрго, оба критически важны, и если вы испытываете только опыт в одном, вы должны заставить кого-то испытать взгляд на другого или улучшить свой собственный набор навыков, где он отсутствует.
Оба важны, но плохой дизайн в любой из вышеперечисленных действий, как правило, сложнее исправить. Например, изменения в функциональных спецификациях, естественно, будут генерировать гораздо больше работы, чем некоторые изменения в языке.
Любые значимые изменения в базе данных, как правило, также требуют изменений в кодировке, поэтому я лично трачу гораздо больше времени, мучительно на решения по дизайну базы данных, а затем на решения по кодированию (хотя я уверен, что я не единственный, кто потратил час или два, пытаясь найти идеальное имя для класса).
База данных - это артефакт компьютерной программы, которая моделирует данный процесс и систему
В идеале это не должно вызывать беспокойства
Текущая технология сохранения объектов еще не совсем там, поэтому, вероятно, некоторые из вас будут беспокоиться в течение некоторого времени
Вопрос: Для чего нужна база данных?
Если это необходимо для сохранения объектов в вашей модели процессов и систем, вам не следует иметь с этим ничего общего.
Если вы хотите исправить дыры в своей модели, вы потратите на это много времени.
IMHO Хороший дизайн базы данных в более важном, чем хорошее кодирование (хорошее кодирование также важно, но сравнивается с дизайном базы данных).
Зависит от того, что вам нравится, но будущее - это абстрагирование слоя данных - то есть, учитывая, что хранилище данных является деталью реализации, а не основным ядром приложения.
В некоторых кругах вы услышите термин "упорство невежества". Цель состоит в том, чтобы модель домена (бизнес-единицы) была разработана без знания того, как данные будут храниться. За кулисами это может быть в SQL, AmazonDB или XML.
Если вам нравится материал DBA, то, где вы должны быть. Но если вы хотите быть более на стороне приложения, познакомиться с инфраструктурой ORM.