Что важнее? БД дизайн или кодирование? [закрыто]

Я могу думать о сценарии, где требуется пустой оператор (не для условия if, а для цикла while).

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

    System.out.println("Enter Y to proceed. Waiting...");
    System.out.println("");

    while(!(new Scanner(System.in).next().equalsIgnoreCase("Y")));

    System.out.println("Proceeding...");
    // do the work here
29
задан 7 revs, 5 users 76% 7 July 2011 в 18:56
поделиться

36 ответов

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

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

Чтобы обратиться к вашему редактированию; Я думаю, что многие люди, пишущие / пишущие на блоге об этом типе проблемы, имеют тенденцию довольно сильно исходить из «кодирующей» стороны вещей, эти типы людей склонны считать дизайн базы данных тривиальным и менее интересным, чем кодирование интересных решений. По сути, для тех, кто любит решать «хитрые проблемы» (а это чаще люди, которые больше пишут в блогах), сторона программирования более интересна, чем фундаментальные проблемы дизайна. И хотя фундаментальные проблемы дизайна не являются «сексуальными», они чрезвычайно важны (а дизайн баз данных - ОЧЕНЬ фундаментальная проблема проектирования).

84
ответ дан 28 November 2019 в 00:32
поделиться

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

<script type="text/javascript">
$(function(){
    $('#thickboxButton').click(function(){
        $('#thickboxId').click();
    });
});
</script>

<input id="thickboxButton" type="button" value="Click me">
<a id="thickboxId" href="myScript.php" class="thickbox" title="">Link</a>

Редактировать:

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

<script type="text/javascript">
$(function(){
    $('#thickboxButton').click(function(){
        window.location = $('#thickboxId').attr('href');
    });
});
</script>

Редактировать 2:

Теперь, когда я понимаю, что Thickbox - это пользовательский jQuery Виджет пользовательского интерфейса, я нашел инструкции здесь :

Инструкции:

0
ответ дан 28 November 2019 в 00:32
поделиться

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

0
ответ дан 28 November 2019 в 00:32
поделиться

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

Есть ли ваше приложение для обработки данных, или данные выходят за пределы вашего приложения?

Другими словами, если кодовая часть вашего приложения взорвалась сегодня, но ваши данные все еще там, насколько страшной была бы катастрофа? Если вы ответите:

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

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

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

РЕДАКТИРОВАТЬ

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

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

РЕДАКТИРОВАТЬ

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

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

РЕДАКТИРОВАТЬ

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

и позже вернемся к любым недостаткам данных.

РЕДАКТИРОВАТЬ

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

и позже вернемся к любым недостаткам данных.

РЕДАКТИРОВАТЬ

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

1
ответ дан 28 November 2019 в 00:32
поделиться

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

1
ответ дан 28 November 2019 в 00:32
поделиться

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

1
ответ дан 28 November 2019 в 00:32
поделиться

Краткий ответ: оба. Цепь так же прочна, как и самое слабое звено.

26
ответ дан 28 November 2019 в 00:32
поделиться

Если вы неосторожны с любым из них, вы обречены.

18
ответ дан 28 November 2019 в 00:32
поделиться

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

  • таблицу клиентов
  • таблицу заказов
  • таблицу продуктов и т. Д.

В вашей ситуации у вас может быть

  • класс таблица
  • таблица учеников
  • таблица оценок и т. д.

Этот общий формат таблицы может использоваться во многих приложениях.

Я бы классифицировал модель данных ОО (классы в Java / C #) как Модель и неразрывно связана со схемой базы данных (с добавленными переходными процессами и вспомогательными методами, конечно). Ваш контроллер - «кодирование» в вашем вопросе - должно действительно реализовать бизнес-логику, используя модель, представленную объектами, которые вы извлекаете из базы данных через DAO / ORM.

8
ответ дан 28 November 2019 в 00:32
поделиться

Модель предметной области не должна зависеть от деталей реализации постоянства (хотя технология накладывает некоторые ограничения на модель) - http://www.infoq.com/articles/ddd-in-practice

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

Книги, которые следует читать, если вы занимаетесь веб-разработкой .NET:

  1. ASP. Предварительный просмотр NET MVC Framework (всего 100 страниц, и вы начнете с него)
  2. NHibernate в действии
  3. Проектирование и разработка на основе доменов на практике (не читайте, но я это сделаю, и это бесплатно)
  4. Рефакторинг: улучшение дизайна существующего кода
6
ответ дан 28 November 2019 в 00:32
поделиться

Это был мой опыт (и я занимался решением проблем с базами данных около 30 лет и занимался сотни разных баз данных), что слишком много проблем с производительностью баз данных являются следствием неуместных попыток повторного использования кода. Функции намного медленнее, чем встроенный код. Курсоры, повторно использующие хранимый процесс, который вставляет одну запись за раз, намного, намного, намного (световые годы) медленнее, чем код на основе набора. Повторное использование процедуры, которая возвращает то, что вам нужно, и десять других полей неэффективно расходуют ресурсы сервера и сети. Использование существующего представления, объединяющего десять таблиц, когда вам нужна информация только из трех из них, приводит к неэффективному использованию ресурсов сервера. Повторное использование кода в базах данных не так хорошо, как в других местах. Это не означает, что код не должен использоваться повторно, если это необходимо. Просто это никогда не должно иметь приоритет над производительностью. К сожалению, базы данных плохо спроектированы для повторного использования кода. Большинство баз данных не являются объектно-ориентированными, и объектно-ориентированное мышление при проектировании или доступе к ним часто приводит к плохому дизайну.

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

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

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

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

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

5
ответ дан 28 November 2019 в 00:32
поделиться

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

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

2
ответ дан 28 November 2019 в 00:32
поделиться

В каком-то смысле вы не можете разделить их: дизайн БД - это кодирование - это просто не кодирование на процедурном языке

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

2
ответ дан 28 November 2019 в 00:32
поделиться

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

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

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

2
ответ дан 28 November 2019 в 00:32
поделиться

Зависит от того, где вы знаете как ..., так и требования к продукту.

Пренебрегайте обеими сторонами и вашими продукт может быть в беде.

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

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

1
ответ дан 28 November 2019 в 00:32
поделиться

Оба

Отличный код может быть разрушен ужасным дизайном БД, а отличный дизайн БД может быть разрушен ужасным код.

1
ответ дан 28 November 2019 в 00:32
поделиться

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

1
ответ дан 28 November 2019 в 00:32
поделиться

Ничто не является важным, но ...

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

5
ответ дан 28 November 2019 в 00:32
поделиться

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

Таким образом, изменение в базе данных - это просто изменение в реализации вашего хранилища. Плохой дизайн базы данных сделает ваш репозиторий трудным для кодирования и медленным, но не повлияет на ваш бизнес-уровень (90% кода).

Если вы попытаетесь изменить бизнес-уровень из-за уровня DAO, почему бы не изменить бизнес-уровень из-за уровня презентации? и тогда удачи, чтобы удовлетворить все ограничения и передовой опыт!

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

0
ответ дан 28 November 2019 в 00:32
поделиться

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

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

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

0
ответ дан 28 November 2019 в 00:32
поделиться

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

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

0
ответ дан 28 November 2019 в 00:32
поделиться

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

В идеале это не должно вызывать беспокойства.

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

Вопрос: Для чего здесь база данных?

Если она существует для сохранения объектов в вашей модели процессов и систем тогда вам не нужно иметь с этим ничего общего.

Если он есть, чтобы исправить дыры в вашей модели, то вы потратите на это много времени

0
ответ дан 28 November 2019 в 00:32
поделиться

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

  1. Просто потому, что в базе данных будут храниться ваши ценные данные.
  2. Плохое кодирование может не повлиять на базу данных, но повлияет на масштабируемость, производительность всего приложения и т. Д. В течение некоторого времени это можно исправить путем рефакторинга (конечно, некоторые связанные с этим затраты).
  3. Рефакторинг базы данных намного более затратный и сложный.
  4. Также обычно у нас работает несколько разных приложений, работающих на одной базе данных, так что это общий фактор.
0
ответ дан 28 November 2019 в 00:32
поделиться

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

В некоторых кругах вы услышите термин «невежество». Цель состоит в том, чтобы модель предметной области (бизнес-объекты) разрабатывалась без знания того, как будут храниться данные. За кулисами это может быть в SQL, AmazonDB или XML.

Если вам нравится DBA, вы должны быть там. Но если вы хотите больше ориентироваться на приложения, познакомьтесь с инфраструктурой ORM.

0
ответ дан 28 November 2019 в 00:32
поделиться

Оба, конечно, важны, это симбиотические отношения.

Но если ваша БД взломана, никакое количество хорошего кода не сможет заставить ваше приложение сиять.

Однако, если ваша БД действительно хороша, то хороший код может сделать ее еще лучше (но плохой код все еще может испортить ее).

1
ответ дан 28 November 2019 в 00:32
поделиться

You DB design is most important.

I'm a coder, and I prefer code, but ... if you screw up the DB design, your code will be a nightmare. Your code won't have a chance!

Even when you try to refactor the DB design, you will have so much work around code, that fixing it all will be overwhelming.

This isn't a preference or even a close one, it's very much leaning toward the DB design being most important.

EDIT: Even if you were to have key-value pair tables where everything got dumped into it, that would still be a DB design based on business requirements.

15
ответ дан 28 November 2019 в 00:32
поделиться

Перефразируя Кнута -

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

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

10
ответ дан 28 November 2019 в 00:32
поделиться

Посмотрите на это так

  1. Изменение кода означает изменение кода
  2. Изменение базы данных, вероятно, также заставит вас изменить код

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

8
ответ дан 28 November 2019 в 00:32
поделиться

I will not attempt to duplicate many of the fine comments made thus far. Nor will I spend any time identifying the dubious statements also made.

But I will add the following points.

If you are like most people you are referring to a RDBMS as the database in your question. An RDBMS is essentially a slave. It listens on a port and is duty bound to attempt to service all requests that come over that port. It has no way of know which of those requests are just plain stupid or ill-advised. Thus it is is easy for the most perfectly designed DB to be abused to the point of locking up the server. This implies that the code is more important. DBAs everywhere can be found pulling out their hair in response to some of the dumber things that app developers throw at the servers they manage.

So the best advice I can give you on the topic is to ensure that the DB is accessed by an API that is written by the same developer who designed the DB. Make it the responsibility of one dude (or one group reporting to the same dude) to ensure sound design decisions are made for both. If you're that dude, then don't skimp on one at the expense of the other. Design your API so that a refactoring of the DB can be done transparently to the clients of the API.

2
ответ дан 28 November 2019 в 00:32
поделиться

мы переписывали веб-сайт 3 раза за 4 года. база данных не изменилась. (ну, немного)

1
ответ дан 28 November 2019 в 00:32
поделиться
Другие вопросы по тегам:

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