Что важнее? БД дизайн или кодирование? [закрыто]
Я могу думать о сценарии, где требуется пустой оператор (не для условия 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
36 ответов
Это ошибка рассуждения о том, что данные принципиально отличаются от исполняемого кода. Теория клеточных автоматов полна примеров, когда данные и код сильно «запутаны».
Но, поскольку выбранный BD менее легко модифицируем, вам следует подумать о глобальной архитектуре. Но если вы не уверены в окончательном варианте, вам следует больше всего подумать о самой легко расходуемой архитектуре BD.
Мой опыт показывает, что модифицировать код легче, чем BD.
Я не могу сказать, что дизайн базы данных важнее, чем дизайн кода, но это по крайней мере то же самое. Если вы написали отличный код, но ваша БД плохая, тогда у вашего приложения будут проблемы с производительностью, и наоборот.
Что касается дизайна БД, то здесь много материалов (включая книги). Посмотрите на тему нормализации базы данных .
"Apps are temporary, but data is permanent"
for me db design is MORE important, it is the foundation of the app you are going to code.
Its important to do both accurately and professionally. To avoid future headaches do it properly now, as changes, fixes or enhancements are much harder when things are set in stone.
The design of the database and how your code interacts with that data, will have a huge impact on your performance and your agility.
I can't say much about importance, but once you've set your database and it's full of millions of rows.. changing it is going to be tricky and time-consuming. Sort of.. the sins of the DBA will be patch-fixed in code.
There's also always the choices you have to make between being agile (creating an extendable database able to solve problems or answer questions you didn't know about when designing it) and performing/scaling well. Again, sometimes it might be better to use code to create a cache outside of the actual DB to create some of that performance.
Наиболее важным является понимание домена. Вы должны понимать, что вы хотите сделать со своим приложением. Из понимания домена необходимо понять, какие виды информации вы планируете хранить, а также отношения между информационными единицами. Вы также должны понимать примеры использования.
После этого наиболее важна разработка базы данных. База данных - это лучшее место для кодификации информации, полученной в результате анализа вашего домена. Как только вы получите необходимые данные, вы должны нормализовать их в максимально возможной степени. Затем вы должны понять диапазон правовых значений для каждого поля и написать процедуры проверки данных для каждого из них (в виде ограничений проверки, хранимых процедур, регексов или чего-то еще, что имеет смысл).
Чаще всего я сталкивался с тем, что когда ваши данные сильно нормализованы, объем кода, необходимый для заполнения вашего приложения, значительно уменьшается по нескольким причинам:
- Вы пишите код не для того, чтобы выполнять поиск, сортировку, индексирование, присоединение и группировку данных. SQL делает многое из этого за вас.
- Нормализованные данные не дублируются. Это означает, что каждое обновление происходит в одном и том же месте. Если Вам приходится писать код, чтобы данные синхронизировались во многих местах, то код становится раздутым и подверженным ошибкам.
- Не нужно писать столько кода для обработки ошибок, потому что его много в коде проверки данных.
- Когда объем вашего кода падает, вам нужно меньше разработчиков для поддержки кода. Это означает, что модули, принадлежащие разным людям, с меньшей вероятностью будут расходиться с общим замыслом программы.
Код все еще важен, но теперь вам просто нужно писать его гораздо меньше.