Лучшие практики: шаблоны программирования приложений баз данных

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

Думаю, мой вопрос лучше всего объяснить на примере. Есть два подхода, которые я сейчас использую, говорят, что у меня есть объект / класс Invoice:

во-первых, использовать статические функции-члены

class Invoice
{
   int id;
   string ref;
   int customer_id;
   date created;
   date due;

   static id create();
   static bool update(id, field1, field2, ...);
   static bool delete(id);
   static bool get(id);
};

Второй подход - поместить все в объект базы данных:

class Database extends ProprietaryDBConnecter, Singleton
{
   id createInvoice();
   bool updateInvoice(id, field1, field2, ...);
   bool deleteInvoice(id);
   bool getInvoice(id);

   id createCustomer();
   bool updateCustomer(id, field1, field2, ...);
   bool deleteCustomer(id);
   bool getCustomer(id);

   // etc...
}

Я обнаружил, что оба способа (SQL) функции-члены очень неотделимы от «представления», в том смысле, что «представление» определяет, что должны иметь классы, и, следовательно, кажется, нарушает архитектуру документа / представления.

Кроме того, это кажется неэффективным, например, оператор SELECT должен выбирать только то, что необходимо, но наличие переменных-членов в Invoice, по-видимому, подразумевает «гарантированные данные».

Не знаю, четко ли я объяснил вопрос: каковы некоторые другие лучшие подходы к этой архитектуре / шаблону проектирования / что это такое известно?

Спасибо за советы

database

— Джейк
источник

Ответы:

Ну, я полагаю, что вы могли бы использовать ORM.

Но на самом деле, дизайн базы данных не должен следовать принципам ООП, он должен следовать принципам дизайна базы данных, таким как нормализация. И это должно быть разработано в базе данных, а не в приложении. И правила целостности данных должны применяться на уровне базы данных, а не приложением.

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

— HLGEM
источник

+1, потому что не все должно быть ООП (даже если некоторые ОРМ довольно хороши!)

— Хавьер

O / RM хороши, но их использование не означает, что вы не можете соответствовать хорошему дизайну базы данных.

— BlackICE

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

— HLGEM

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

— Джон Онстотт

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

— HLGEM

Я не могу найти структуру, которая дополняет ООП подход, который инкапсулирует реализацию базы данных

Похоже, вы описываете несоответствие объектно-реляционного импеданса .

Есть ряд вещей, которые должны решить эта OODBMS, инструменты ORM, множество инструментов доступа к данным.

Я думаю, что тот факт, что существует так много решений, заставляет меня поверить, что One True Solution ™ не существует.

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

— Конрад Фрикс
источник

Похоже, что это более жестким образом.

— Джейк

Если вы не хотите использовать оболочку ORM, используйте базу данных, которая поддерживает хранилище в стиле ООП, например MongoDB .

MongoDB (из «ху Монго нас») является кросс-платформенный документ-ориентированной базы данных системы. Классифицированный как база данных « NoSQL », MongoDB отказывается от традиционной структуры реляционной базы данных на основе таблиц в пользу JSON- подобных документов с динамическими схемами (MongoDB называет формат BSON ), что делает интеграцию данных в определенных типах приложений более простой и быстрой. ..

— Джош К
источник