Кращі практики: схеми програмування додатків для баз даних


11

Поки що я написав багато веб-додатків бази даних (MySQL), але завжди думаю, що моя структура ніби незграбна. Я хочу вдосконалити схему програмування / дизайну, яку я використовую, сподіваючись на деякі поради тут. Зокрема, я не можу знайти структуру, яка доповнює підхід OOP, який інкапсулює реалізацію бази даних (схеми). Я

Подумайте, моє питання найкраще пояснити на прикладі. Я використовую 2 підходи, які кажуть, що у мене є об'єкт / клас рахунків-фактур:

По-перше, це використовувати статичні функції членів

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 повинен вибрати лише те, що потрібно, але наявність змінних членів у рахунку-фактурі, здається, означає "гарантовані дані".

Не знаю, чи я пояснив це питання чітко: Які ще найкращі підходи до цієї структури архітектури / дизайну / що - це - відомо?

Дякую за поради

Відповіді:


14

Я припускаю, що ви можете використовувати ORM.

Але дійсно, дизайн бази даних НЕ повинен дотримуватися принципів OOP, він повинен слідувати принципам проектування бази даних, таким як нормалізація. І він повинен бути розроблений на базі даних, а не в додатку. А правила цілісності даних повинні виконуватись на рівні бази даних, а не додатком.

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


5
+1, бо не все повинно бути OOP (навіть якщо деякі ORM дуже приємні!)
Хав'єр

1
O / RM є приємними, але їх використання не означає, що ви не можете відповідати гарному дизайну бази даних.
BlackICE

1
@David, я погоджуюся, що це правда в руках того, хто знає, що робить. І я запропонував йому подивитися на ORM, але якщо ви не знаєте спочатку дизайн бази даних, ORM - це небезпечний інструмент.
HLGEM

Це хороший момент, що правила цілісності даних можна застосовувати на рівні бази даних. Однак іноді має сенс помістити деякі правила (наприклад, «проект завжди повинен містити більше 5 членів команди») у заявку, якщо правила можуть бути змінені, і лише додаток буде змінювати дані.
Джон Онстотт

Додаток майже ніколи не є єдиним, що змінює дані. Правила бізнесу, які не вводяться в базу даних, зазвичай дуже легко порушуються, коли комусь потрібно швидко змінити великий фрагмент даних, щоб підтримати певні виправлення даних.
HLGEM

10

Я не можу знайти структуру, яка доповнює підхід OOP, який інкапсулює реалізацію бази даних

Схоже, ви описуєте невідповідність об'єктно-реляційного опору .

Існує ряд речей, які повинні вирішити цей інструмент OODBMS, ORM, безліч інструментів доступу до даних.

Я думаю, що факт, що існує так багато рішень, змушує мене вважати, що One True Solution ™ не існує.

Таким чином, ви можете вибрати будь-який напрямок, який вам подобається, захищений, знаючи, що деякі люди будуть його ненавидіти, а деякі люблять.


Схоже, це є, більш жорстким чином.
Джейк

2

Якщо ви не хочете використовувати обгортку ORM, використовуйте базу даних, яка підтримує сховище стилю OOP, наприклад MongoDB .

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.