Что такое более быстрые, плоские файлы или база данных MySQL RAM?

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

Если вы просто ищете для максимально быстрого обмена данными и сохранения их в ОЗУ, тогда memcached - идеальное решение.

Если вы хотите сохранить данные, используйте СУБД, например MySQL.

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

Что-нибудь кроме тривиального обмена данными, но я бы выбрал БД.

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

Поэтому вам в любом случае понадобится серверная база данных, чтобы обеспечить совместное использование данных между веб-серверами. Если ты'

Я бы сказал, что MySql DB будет лучшим выбором, если у вас нет какого-либо механизма для работы с блокировками плоских файлов (и некоторого способа управления доступом). В этом случае уровень БД (независимо от конкретной СУБД) действует как косвенный уровень, позволяя вам не беспокоиться об этом.

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

Если в вашей системе есть кэш PHP (который кэширует скомпилированный код PHP в памяти, например APC), попробуйте поместить ваши данные в файл PHP в виде кода PHP. Если вам нужно записать данные, есть некоторые проблемы с безопасностью.

Мне нужен простой способ для нескольких запуск сценариев PHP для обмена данными.

APC и memcached - хорошие варианты в зависимости от контекста. совместно используемая память также может быть вариантом.

Следует ли мне создавать базу данных MySQL с ОЗУ механизм хранения и обмен данными через что (может несколько скриптов подключаться к одна и та же БД одновременно?)

Это тоже неплохой вариант, но, вероятно, он не будет таким быстрым, как APC или memcached.

Или плоские файлы с одним фрагментом данные на строку лучше?

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

Если это хранилище данных, к которому могут обращаться одновременно несколько авторов, ни в коем случае НЕ используйте плоский файл! Запись в плоский файл из нескольких процессов может привести к повреждению файла. Вы можете заблокировать файл, но вы рискуете вызвать конфликты блокировок и длительное время ожидания блокировки.

Обработка одновременных операций записи является причиной существования таких приложений, как mysql и memcached.

Вы используете схему под названием полиморфные ассоциации , и это часто делается неправильно. Чтобы заставить его работать, нужно создать другую таблицу, скажем, members: abstract :

CREATE TABLE IF NOT EXISTS `members:abstract` (
 `id` INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
 `type` enum('class','elected','appointed','status') NOT NULL,
  UNIQUE KEY (`id`, `type`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Эта таблица служит родительской таблицей для всех таблиц атрибутов ваших элементов. Каждая из этих таблиц меняет свой первичный ключ на , а не на , генерирующие значения идентификаторов автоматически, а вместо этого ссылаются на первичный ключ членов: abstract . Я покажу только членов: назначено , но остальные будут похожи.

CREATE TABLE IF NOT EXISTS `members:appointed` (
 `id` INT UNSIGNED NOT NULL PRIMARY KEY, -- not auto_increment
 `name_prefix` varchar(8) collate utf8_bin NOT NULL COMMENT 'Prefix Added to Members Name',
 `hours_extra` decimal(4,2) NOT NULL COMMENT 'Hours Given as Bonus for Holding this Position.',
 `position` varchar(40) collate utf8_bin NOT NULL COMMENT 'Name of the Posisiton',
 FOREIGN KEY (`id`) REFERENCES `members:abstract` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Undefined within the SOP or By-Laws.';

Вы можете заставить эту таблицу автоматически генерировать автоматически генерируемые значения с помощью триггера:

DELIMITER //
DROP TRIGGER IF EXISTS ins_appointed//
CREATE TRIGGER ins_appointed BEFORE INSERT ON `members:appointed`
FOR EACH ROW BEGIN
  INSERT INTO `members:abstract` (`type`) VALUES ('appointed');
  SET NEW.id = LAST_INSERT_ID();
END; //
DELIMITER ;

Сделайте то же самое для каждого из остальных таблицы атрибутов.

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

Затем вы создаете членов: Плоский файл может работать быстрее, чем база данных, но в очень специфических приложениях. Они работают быстрее, если данные читаются от начала до конца без какого-либо поиска или записи. Если данные не помещаются в памяти и должны быть полностью прочитаны для выполнения работы, они «могут» быть быстрее, чем база данных. Кроме того, если записи намного больше, чем чтения, плоский файл также светится, большинство настроек баз данных по умолчанию должны будут заставить запросы чтения ждать завершения записи, чтобы поддерживать индексы и внешние ключи. Выполнение запросов записи обычно медленнее, чем простое чтение.