Код Перший проти Першої бази даних

Коли я розробляю і створюю програмне забезпечення, над яким я працюю, я, як правило, спочатку проектую і створюю резервні таблиці SQL, а потім переходжу до власне програмування. Проект, над яким я зараз працюю, хоч і мене спантеличив правильно. Це, мабуть, пов’язано з відсутністю хороших, твердих вимог, але я, на жаль, цього не можу зробити. Це така ситуація "просто йди, щоб це сталося" .. але я відступаю.

Я думаю про перегляд мого робочого процесу на голову та створення спочатку класів моделей інтерфейсу та даних, сподіваючись, що розробка цього моменту дасть зрозуміти мені, як буде виглядати моя схема бази даних в кінцевому підсумку. Це гарна ідея? Мені нервує, що я закінчую користувальницьким інтерфейсом і досі не знаю, як структурувати db.

Якщо комусь цікаво, я використовую SQL Server як бекенд, а MS Access - як передній додаток. (Доступ теж не мій вибір ... тому, будь ласка, не ненавидіти його занадто погано.)

Що було першим, процес чи дані, які використовували цей процес? Я знаю, що це якесь питання "курка чи яйце", але у випадку програмного забезпечення я вважаю, що це процес.

Наприклад, ви можете створювати свою модель даних поступово, впроваджуючи один окремий випадок використання за один раз із простою пам'яттю (або що-небудь настільки просте в реалізації). Коли вам здається, що ви реалізували достатньо випадків використання для того, щоб окреслити основні сутності, ви можете замінити стійкість пам’яті справжньою базою даних, а потім продовжувати вдосконалювати схему, рухаючись вперед, по одному випадку використання за один раз.

Це виводить фокус із бази даних і переміщує її до основи проблеми: бізнес-правил. Якщо ви почнете з реалізації бізнес-правил, ви зрештою знайдете (до речі, процес, подібний до Natural Selection), які дані справді потрібні бізнесу. Якщо ви почнете з моделювання бази даних, без зворотного зв’язку про те, чи справді потрібні ці дані (або в такому форматі, або в такому рівні нормалізації тощо), ви або в кінцевому підсумку зробите багато пізніх коригувань у схему (яка може зажадати важких процедур міграції, якщо бізнес вже працює з нею), або вам доведеться реалізувати "робочі обходи" в бізнес-правилах, щоб скласти модель, що не відповідає настроюванню даних.

TL; DR: База даних залежить від бізнесу - вона їх визначає. Дані вам не знадобляться, якщо у вас немає процесу, який працює з ними (звіт - це також процес). Спершу реалізуйте процес, і ви знайдете, які дані йому потрібні. Спершу моделюйте дані, і ви, можливо, зможете порахувати, скільки припущень було неправильним, коли ви вперше моделювали їх.

Трохи поза темою, але дуже важливо: робочий процес, який я описую, часто використовується разом із дуже важливими практиками, такими як "Найпростіша річ, яка могла б працювати", тестова розробка та фокус на роз'єднанні вашої архітектури від деталей, які стати на шляху (підказка: база даних). Щодо останнього, ця розмова досить добре підводить ідею.

Аналіз першопричини дозволяє припустити, що ця проблема не є методом, але є відсутністю специфікації. Без жодного не важливо, що ви пишете спочатку - ви все одно викинете це.

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

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

Мій досвід такий:

• У більшості проектів, над якими я працював, ми спершу створили базу даних.
• Часто дані вже існують у електронних таблицях, застарілих базах даних, на папері тощо. Ці дані дають вам підказки про таблиці, необхідні для їх зберігання.
• Часто час уже використовується процес, але вручну або використовується декілька різних інструментів, які не є автоматизованими, не взаємодіють та / або не відповідають стандартам.
• Після того, як у вас є напівзріла модель бази даних, ви можете почати розробляти прототипові форми, вікна і т.д.
• Як ви продовжите, для змін, які спочатку не розглядалися, потрібно буде внести деякі зміни.

Також пам’ятайте:

• Це вже не світ із однією програмою <-> одна база даних. Можливо, вашому додатку доведеться читати або записувати дані з більш ніж однієї бази даних, або ваше рішення буде містити більше одного додатка, використовуючи ту саму базу даних.

Висновок: рекомендую спершу розробити базу даних.

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

Але потім я хоч про це трохи більше, і я зрозумів, що те, що ми насправді робимо на більш успішних великих проектах, - це "спочатку вимоги".

Хороший чітко визначений набір бізнес-вимог призводить до гарного набору функціональних вимог. Якщо у вас є гарний набір функціональних вимог, то модель даних та специфікації модуля просто потрапляють на місце без особливих зусиль.

Оскільки це здається настільки рідким / не визначеним, я спершу зробив би інтерфейс інтерфейсу інтерфейсу - це звучить як те, що вам потрібно, щоб отримати відповіді, підтримку, час та відгуки від зацікавлених сторін, правда? Вони не переймаються вашими блискучими нормалізованими таблицями та обмеженнями зовнішніх ключів та каскадними делетами. Але крутий графічний інтерфейс з великою кількістю блискучих кольорів - ну, це найвищий рівень!

Для початкової "бази даних", використовуйте щось надзвичайно просте, можливо, просто ключі / значення, збережені у файлі. Я незнайомий з MS Access, тому не знаю, яким був би "легкий" найсильніший "бекенд". (Таблиця з електронними таблицями?) Що б не було швидко і брудно, плануйте його викидати.

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

Тепер, можливо, ваші зацікавлені сторони є експертами з БД - це було зі мною часом! - у такому випадку зробіть кілька конструкцій БД.

Оскільки вимоги не зрозумілі, можна почати з дуже рудиментарної моделі даних з ключовими елементами, які ви знаєте, що вам потрібно, можливо, лише базовими таблицями та ПК. Решту даних серіалізуйте у двійкові чи XML та зберігайте BLOB у базі даних для початку. Це повинно дозволяти розробляти інтерфейс користувача та бізнес-рівень (середній рівень) без повністю реляційної моделі, але у вас все одно буде наполегливість зберігати та отримувати та прості пошуки ключів за необхідності.

Як приклад, можливо, у вас є Особа, тому у вас є PK Person Id. Решта атрибутів не відомі, тому почніть з таблиці Person з ідентифікатором особи ПК та іншим стовпцем, який зберігатиме Blob, усі дані про людину.

Після того як вимоги зміцняться, візьміть ваші Blobs і витягніть всі необхідні таблиці та стовпці та зробіть модель реляційною. Тоді справа лише в зміні стійкості з BLOB на реляційну в рівні доступу до даних. Але все інше, бізнес-правила інтерфейсу користувача тощо працюватимуть. Зауважте, це додає деякий час проекту, але дає можливість для повної гнучкості додавати та відмовляти речі за необхідності, не змінюючи реляційну модель, поки речі не стануть більш чіткими.

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

В основному ви починаєте з табличної моделі і переходите до реляційної в міру просування проекту.

Або сформулюйте вимоги перед початком будь-якої роботи, щоб спочатку була розроблена реляційна модель.

Взагалі я думаю, що код надходить після даних, тому що код маніпулює даними.

Якщо вимоги не зрозумілі, ви можете створити модель даних для свого тлумачення вимог. Найкраще, можливо, записати якісь вимоги і надіслати їх своєму роботодавцю, тоді вони мають на що звернути увагу. Або створити спочатку gui, це залежить від типу роботодавця, що найкраще працює :)