Коли одне фактичне значення даних жорсткого коду вводиться в код на відміну від використання БД?

Давним питанням для мене було: коли я зберігаю дані (фактичні значення) в таблиці бази даних, і коли я зберігаю їх прямо в коді?

Незгаданий консенсус, як правило, є таким (*):

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

[* консенсус обговорювався в коментарях та відповідях, але в основному я хотів би якоюсь передумовою перейти до старту питання, тому сміливо кидайте виклик і вдосконалюйте його ]

Приклад:

$number = 44;
$colors = array("blue", "yellow", ... "mauve");

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

Але, здається, є сіра зона; як щодо випадків, які не так зрозумілі? На які міркування та фактори потрібно звернути увагу, щоб прийняти рішення?

Приклад:
Скажімо, ваша компанія використовує 10-15 різних типів каркасів двигунів, які можна представити як "412T". У вас їх близько 30, і вони змінюються рідко. Ви можете створити таблицю БД для них або жорсткий код у базі даних. У цьому випадку мотори - це статичні, фізичні речі, які, швидше за все, не змінюються часто.

Утримуючи їх у коді, вони піддають їх контролю джерелом, де в базі даних зміни БД, як правило, не відслідковуються. Але зберігання їх у базі даних звільняє (відокремлює) код від даних.

Інший (фактичний) приклад, який я можу використати, - це моє питання: /programming/26169751/how-to-best-get-the-data-out-of-a-lookup-table (наразі 48 рядки даних опції).

Я не думаю, що ці два твердження справді не є єдиною думкою щодо того, коли потрібно вводити жорсткі кодові дані:

Якщо це єдина змінна або проста структура, або масив з кількох значень, введіть дані прямо в код

Якщо в ньому є сотні + рядків даних одного типу, використовуйте базу даних

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

Натомість я спершу зосередився б на питанні:

• Як часто змінюються дані?

• Кому може знадобитися це змінити?

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

Якщо відповідь "хто це змінить" - це "хтось, крім програміста", тоді вам не слід жорстко кодувати дані.

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

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

Я б пішов з третім варіантом: конфігураційний файл!

Для додатків, над якими я працюю (в Java, тому всі мої приклади використовують Java + Spring), такі значення зазвичай зберігаються у конфігураційних файлах та вводяться (через Spring) у код, який їм потрібен під час запуску програми. У файлі властивостей:

motorFramesString=412T, 413T, ...

Налаштування навесні:

<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames" value="${motorFrames}"/>
</bean>

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

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

Складніший приклад, як-от те, що ви посилаєте, може бути зроблено також із властивостями або з ними.

У products.properties:

productA.name=Product A 123
productA.hasMotor=true
productA.numFeet=1
productA.hasOutlet=true
productA.needsManual=true

productB.name=Product B 456
productB.hasMotor=false
productB.numFeet=1
productB.hasOutlet=true
productB.needsManual=true

У своєму весняному конфігураційному файлі:

<bean name="productA" class="com.mycompany.Product">
   <property name="name" value="${productA.name}"/>
   <property name="hasMotor" value="${productA.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<bean name="productB" class="com.mycompany.Product">
   <property name="name" value="${productB.name}"/>
   <property name="hasMotor" value="${productB.hasMotor}"/>
   <!-- rest omitted for brevity -->
</bean>
<!-- configure as many beans as needed -->
<bean="motorFrameManager" class="myCompany.MotorFrameManager" >
    <property name="motorFrames"> <!-- assumes that MotorFrameManager has a property motorFrames which is a List<Product> -->
        <list>
            <ref bean="productA"/>
            <ref bean="productB"/>
        </list>
    </property>
</bean>

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

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

Частота

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

Хто

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

Загальна нитка

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

Тестування

Обов’язково пишіть одиничні тести, які підтверджують ваше програмне забезпечення в різних конфігураціях. Можливо, ваш клієнт вмикає необов’язкове підказку або переробляє один метр на дванадцять футів. Незалежно від того, наскільки обґрунтовані зміни, якщо ваше програмне забезпечення це дозволяє, чорт забирає краще підтвердити, що зміна працює так, як очікувалося, незалежно від того, наскільки вона неправільна.

Зберігати дані не частота змін, ані кількість даних.

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

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

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

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

Тож питання, яке вам слід задавати, - це не "як часто воно буде змінюватися?", А "чи може воно змінитися?". Якщо значення для властивості може змінюватися в межах однієї ітерації коду (не торкаючись нічого іншого в коді) у виробничому середовищі, воно переходить у базу даних.

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

Якщо ви зберігаєте подібні дані в базі даних, завжди є можливість когось змінити їх на льоту і повністю змінити поведінку системи.

Інша проблема полягає в тому, що не існує простого способу отримання записів до бази даних через управління джерелами управління / зміни змін / системи автоматичного збирання, які ви повинні використовувати.

Одне, що ви ніколи не повинні зберігати в базі даних, - це реквізити, необхідні для доступу до бази даних.
У вас є трохи лову-22, якщо вам потрібно отримати доступ до бази даних для отримання рядків підключення, імені користувача та пароля для тієї самої бази даних.

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

Звичайно, ви можете зберігати інформацію про базу даних у цьому конфігураційному файлі в зашифрованому вигляді, але тоді вам потрібно буде де-небудь зберігати ключі дешифрування, і це було б майже напевно закодовано.

Крім цього, є речі, які ніколи не змінюються. Такі речі, як природні константи (G, pi, e, ви їх називаєте), такі речі, як певні регулярні вирази, як перевірка електронної пошти.