Когда следует жестко кодировать данные внутри исходного кода, когда использовать базу данных и когда использовать веб-сервис?

Question

Когда следует жестко кодировать данные внутри исходного кода, когда использовать базу данных и когда использовать веб-сервис?

Рассмотрим класс ниже, где некоторые данные, связанные с продуктом и его компонентами, жестко запрограммированы в исходном коде.

class ProductCharacteristics
{
private $model;

function __construct($model)
{
$this->model = $model;

//Since there are several product models,
//we hardcode each model separately.
//models are 50, 100, 200

//length
$this->length[ 50] = array(5.5, 5.5, 5.5, 5.5, 5.5, 5.5, 5.5, 5.5, 5.5);
$this->length[100] = array(5.5, 5.5, 5.5, 5.5, 5.5, 5.5, 5.5, 5.5, 5.5);
$this->length[200] = array(5.5, 5.5, 5.5, 5.5, 5.5, 5.5, 5.5, 5.5, 5.5);

//weights
$this->weight[ 50] = array(20, 114, 50);
$this->weight[100] = array(68, 192, 68);
$this->weight[200] = array(68, 192, 68);

//descriptions
$this->description[ 50] = array('3"', '3"', 6.50);
$this->description[100] = array('6"', '6"', 6.50);
$this->description[200] = array('6"', '6"', 6.50);

}

public function getLengths()
{
return $this->length[$this->modelNumber];
}

public function getWeights()
{
return $this->weight[$this->modelNumber];
}

public function getDescriptions()
{
return $this->description[$this->modelNumber];
}
}

//instantiate:
$pc = new ProductCharacteristics(50);
$weight = $pc->getWeight();
print 'weight of component 1 is ' . $weight[0];
print 'weight of component 2 is ' . $weight[1];

Вопрос 1:

Если данные этого типа (небольшие, редко изменяющиеся) кодируются (помещаются) в базу данных. Почему или почему нет? Я ищу больше, чем просто да / нет. Ищу немного объяснений / истории / обоснования.

Вопрос 2:

Причина, по которой я решил жестко закодировать ее, а не помещать в базу данных, заключалась в том, что у меня сложилось впечатление, что «обращение к базе данных для такого небольшого набора данных является дорогостоящим и непомерным». Если бы у меня было 2MiB таких данных, я бы, конечно, не поместил бы их в исходный код. Но так как набор был небольшим, я поместил его в исходный код с дополнительным преимуществом, заключающимся в том, что, если какой-либо элемент данных изменится, это изменение будет отслеживаться в моем репозитории контроля версий. Я не смог бы узнать об изменениях, если бы они произошли на уровне базы данных

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

Вопрос: это «большое дело» или сравнительно «не большое дело», если вместо этого закодировать эти данные в базе данных? То есть, если жесткое кодирование данных в исходном коде — это O (1), какова большая разница в размещении их в базе данных?

Это похоже на {время доступа, накладные расходы} на жесткое кодирование данных в исходном коде?
Я, по крайней мере, вижу использование базы данных как O (2), потому что мы должны задействовать внешнюю программу, систему баз данных для получения данных.

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

1

data-storage database php storage web-services

Решение

Другие решения

По вопросу 1:

Поместите в базу данных / СУБД все, что вы можете использовать для запроса. Затем СУБД может использовать его для оптимизации, целостности и ясности.

СУБД может оптимизировать все запросы.
Например: если вы используете код структуры данных ORM в сочетании с запросом к базе данных, то СУБД, возможно, придется циклически проходить по перекрестному произведению двух таблиц, проверяя вес $pc->getWeight() тогда как он мог бы избежать перекрестного продукта, присоединившись к ProductCharacteristics ранее. Например: некоторые всегда правда вещи, которые вы можете сказать СУБД, которые помогают оптимизировать запросы, UNIQUE NOT NULL (в том числе PRIMARY KEY) а также FOREIGN KEY ограничения.
Вы можете запросить все база данных напрямую через SQL.
В противном случае СУБД имеет самый данных и общего оптимизированного интерфейса, но вы не можете запросить, используя вашу структуру данных ORM, без компиляции кода приложения.
Вы можете упростить код ORM.
Поскольку код ORM транслируется в запросы SQL, при использовании только базы данных доступны функции ORM, которых в противном случае не было бы. Например: вычисление коммутативных функций весов с помощью оконных функций SQL.
Вы можете просто запросить отношения приложения, отличающиеся от вашей структуры данных ORM.
Например: легко определить вес определенного компонента с помощью структуры данных ORM, но нелегко найти компоненты определенного веса. Но это одинаково просто через СУБД.
Вы можете лучше поддерживать целостность.
Например: формат таблицы СУБД и / или ограничения целостности требуют эквивалентности одинаковой длины ваших массивов.

Реляционная модель была разработана для решения такого рода проблем со структурами данных и иерархическими базами данных. (Читайте об этом.) Используйте его силу.

По вопросу 2:

Это большое дело. (См. Вопрос 1)

это «большое дело» или сравнительно «не большое дело», если вместо этого закодировать
эти данные в базе данных?

Ваши преимущества ограничены и ограничены.
Вы думаете об отдельных небольших запросах в изоляции. Принимая во внимание, что СУБД существует для произвольных запросов с автоматической реализацией с оптимизацией.

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

Вы замедление нетривиальные запросы.
Вы экономите небольшую (в терминах СУБД) постоянную связь & стоимость оценки небольших запросов для больших затрат оценки больших запросов из-за затруднения оптимизации СУБД. СУБД знает, что таблица мала по статистике. Учитывая небольшую таблицу и запрос, все СУБД делает это просто перебирая массив в памяти. (И почитайте про SARGability.)

с дополнительным преимуществом, что если какой-либо из базовых изменений, изменение
отслеживается в моем хранилище контроля версий

Вы введения исключение.
Вы повторно используете код, но, учитывая, что все остальные данные должны быть зарегистрированы / отслежены, без необходимости. Действительно, ваш код и база данных должны отслеживаться вместе. Хорошая СУБД имеет как регистрацию обновлений, так и отслеживание версий (включая код). Используй это. Во всяком случае, вы всегда можете отслеживать СУБД UPDATE скрипт в вашем репозитории управления исходным кодом.

То есть, если данные в исходном коде жестко закодированы как O (1), что является большим
поместив его в базу данных вместо

Я, по крайней мере, вижу использование базы данных как O (2), потому что мы должны задействовать
внешняя программа, система базы данных, чтобы получить данные

Узнайте о биг-о.
O (1) является O (2) является O (3) является константой. Вы имеете в виду O (1) с разными постоянными коэффициентами. Дополнительные уровни реализации, как правило, в худшем случае постоянны, но в лучшем случае намного лучше из-за оптимизации с использованием информации из более широкой области.

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

2

Шаг 0

Многое уже было сказано. Просто для уточнения.

Википедия говорит:

База данных представляет собой организованный сбор данных.

Таким образом, текстовый файл, реляционная база данных или даже ваш старый блокнот — это базы данных.

Все виды баз данных имеют свои плюсы и минусы.

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

Текстовые конфигурационные файлы предоставляют понятный человеку синтаксис и их основная цель просто отделить конфигурацию от реализации (логика вашего кода).

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

Ответы.

1. Если вы даже не планируете изменять (т. Е. Заменять значения, добавлять новые настройки и т. Д.) Данные в приложении или будущих приложениях на основе этого класса — просто используйте жесткий код. Это не плохо, если вы чувствуете себя достаточно маленьким (или вы — независимый разработчик). Это проще

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

Конфиги Php используются Zend Framework и Yii. Symfony предпочитает хранить конфиги в yml, но также поддерживает php, xml и аннотации (особые виды комментариев, используемые для конфигов магазина).

Для предотвращения предупреждений и для указания значений по умолчанию я использую это учебный класс.

Если вы планируете создать интерфейс для редактирования настроек (например, через HTML-форму в области приложения администратора), используйте реляционную базу данных. Это гораздо лучше для одновременной записи, чем обычный файл. Конфигурация базы данных также полезна, если у вас толстый слой базы данных (например, триггеры).

2.

Преждевременная оптимизация — корень всего зла. [Дональд Кнут]

2

Для небольших статических наборов данных ничтожно мало хранить их или жестко кодировать. Вы говорите один удар по БД, чтобы получить данные, а затем анализировать время по сравнению с его кодированием. Основной выигрыш в производительности будет заключаться в том, что жестко запрограммированное средство означает, что opcache сохраняет данные против попадания в БД каждый раз. Если мы не говорим о приложении, получающем сотни тысяч просмотров, вы говорите менее чем за 1 секунду обработки запроса, который большинство систем СУБД (например, MySQL) будет кэшировать для получения готовых возвратов (запись> чтение для использования системных ресурсов). ,

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

1

Я настоятельно рекомендую иметь все данные в каких-то конфигурационных файлах или базе данных наверняка. Тем не менее, нет никаких ограничений на жесткое кодирование небольших данных, но вот как я объясню ..

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

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

Мое лучшее предложение, чтобы сделать что-то подобное, конечно, если не база данных ..

Создайте файл данных как «data.lengths.php»

<?php
return array(
50 => array(
5.5, 5.5, // can have as many as you want..
)
);

Вы можете подготовить те же файлы данных для других.

и затем вы можете просто использовать его там, где вы хотели бы использовать его как.

<?php

$data['length'] = require_once(__DIR__.'/data.lengths.php'); // Assuming both files are in same directory.

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

Мои 2 цента, надеюсь, это поможет.

0

Источник

Accepted Answer

Ответ 1

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

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

Ответ 2

В 99% случаев хранить данные в базе данных не составляет особого труда. Иначе, почему они существуют? Для доступа к базе данных речь идет о задержке / накладных расходах. Если ваш сервер баз данных находится в том же экземпляре ОС, что и ваша программа, то задержка в сети отсутствует, и накладные расходы будут зависеть от сочетания вашей структуры базы данных и базовой архитектуры хранения (RAM / HDD / SSD). Для большинства проектов, не связанных с масштабированием в миллионы / миллиарды, подойдет любое развертывание общей базы данных.

2