Слабо связанное проектирование баз данных - как к?

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

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

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

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

Интересный комментарий о безопасности базы данных, когда данные вводятся через внешние источники, такие как скрипты базы данных.