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

1

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

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), потому что это внешняя система, и мы должны сделать вызов внешней системе, а также вес для задержки в сети.

  • 0
    @ Ахмад Какова частота доступа к этим данным? Один, два, сто раз в секунду? минут? час? Как часто это меняется или насколько вероятно, что это изменится? Например, содержит ли он цены, которые часто меняются (в течение недели или месяца) или что-то еще?
  • 0
    В самом вопросе, похоже, недостаточно технической информации о хранящихся данных, их удобстве использования и т. Д., Что затрудняет приведение вам примеров, поскольку они могут не относиться к вашему конкретному случаю. Я бы, например, хранить информацию о продукте в базе данных, независимо от того, насколько она мала. Если вы беспокоитесь о том, как или кто изменил данный продукт, вы можете снова иметь соответствующие таблицы для хранения сделанных изменений и тому подобное. Как будет работать сеть, - это еще один вопрос, который зависит от вашей инфраструктуры или от того, что у вас есть для выполнения поставленной задачи, это слишком широкий вопрос!
Показать ещё 1 комментарий
Теги:
database
web-services
storage
data-storage

5 ответов

2

Шаг 0.

Больше всего уже сказано. Только для разглаживания.

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

База данных - это организованная коллекция данных.

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

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

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

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

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

Ответы.

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

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

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

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

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

2.

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

Поделиться
2

Вопрос 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 теперь - "преждевременная оптимизация" ("корень всего зла"). Этот вид инженерных компромиссов следует эмпирическим подозрениям, расследованию и демонстрации с последующим анализом затрат и выгод (включая альтернативные издержки).

Поделиться
  • 0
    Мне придется прочитать ответ еще несколько раз, но в целом ваш совет выглядит следующим образом: поместите все, что вы можете поместить в базу данных. Это может быть изменение парадигмы, потому что, например, в исходном коде может быть много значимых для бизнеса констант и различных небольших разрозненных фрагментов данных, которые, возможно, могут быть помещены в базу данных? Является ли "Все данные в базу данных, всегда" хорошая вещь? Это кажется интересным как концепция / парадигма. Спасибо тебе за это.
  • 0
    Еще одно замечание - я немного смущен тем, что вы используете термин «структура данных ORM». Вы имеете в виду жестко закодированные данные в коде? Потому что, на мой взгляд, структура данных ORM - это хорошая вещь - класс, инкапсулирующий структуру данных (но не сами данные). В ответ вы говорите, что структура данных ORM является корнем всего зла (?)
Показать ещё 1 комментарий
2

Ответ 1

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

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

Ответ 2

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

Поделиться
1

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

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

Поделиться
0

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

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

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

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

Создайте файл данных как "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 цента, надеюсь, это поможет.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню