Выяснение наиболее эффективного способа для пользовательского сервера баз данных (PHP)

Question

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

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

Это означает, что мне нужно создать 2 сценария:

1. База данных-сервер-скрипт
2. Приложение.

Это означает, что приложение должно взаимодействовать с сервером. Моя идея заключалась в использовании php в режиме cli для сервера базы данных. Вопрос в том, эффективен ли он, или мне стоит взглянуть на язык программирования, такой как c ++, для разработки серверного приложения? Второй вопрос - это общение. Когда я использовал php в режиме cli, я подумал о том, чтобы задать запрос serialized-array-query в качестве параметра. При использовании C ++ я должен все еще делать это сериализованным? или может в json, или как там?

Я должен отметить, что база данных для поиска может состоять из нескольких тысяч записей. Так что я не знаю точно, действительно ли php правильный выбор. Во-вторых, я должен отметить, что запросы - это не строки, которые нужно анализировать, а массив, дающий ключ, фильтр значений или набор данных. Единственное, возможно, более сложное, что сервер базы данных должен уметь - это сравнивать строки, такие как версия MySQL LIKE «% VALUE%», которая может быть медленной при нескольких тысячах записей.

Спасибо за помощь.

Answer 1

написание специальной базы данных, которая подходит для одной цели

Полагаю, вы имеете в виду собственную систему управления базами данных,

У меня много трудностей, когда я понимаю, почему это когда-нибудь понадобится.

Datasbes и таблицы, как и обычные базы данных. Но у меня нет колонок. Каждая запись может иметь свои собственные столбцы, кроме идентификатора

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

Я мог бы использовать MySQL ID | сериализованные данные ... но тогда очень весело искать определенный параметр в записи

Так что же не так с полностью полиморфной моделью, реализованной поверх реляционной базы данных:

CREATE TABLE relation (
   id INTEGER NOT NULL auto_increment,
   ....
   PRIMARY KEY (id)
);
CREATE TABLE col_string (
   relation_id NOT NULL /* references relation.id */
   name VARCHAR(20),
   val_string VARCHAR(40),
   PRIMARY KEY (relation_id, name)
);
CREATE TABLE col_integer (
   relation_id NOT NULL /* references relation.id */
   name VARCHAR(20),
   val_integer INTEGER,
   PRIMARY KEY (relation_id, name)
);
CREATE TABLE col_float (
   relation_id NOT NULL /* references relation.id */
   name VARCHAR(20),
   val_float INTEGER,
   PRIMARY KEY (relation_id, name)
);

... и таблицы для больших двоичных объектов, дат и т. Д.

Или если масштабируемость не является большой проблемой ....

CREATE TABLE all_cols (
   relation_id NOT NULL /* references relation.id */
   name VARCHAR(20),
   ctype ENUM('string','integer','float',...),
   val_string VARCHAR(40),
   val_integer INTEGER,
   val_float INTEGER,
   ...
   PRIMARY KEY (relation_id, name)
);

Да, вставка и выбор 'строк' сложнее, чем для обычной реляционной таблицы, но намного проще, чем написание собственной СУБД с нуля. И вы можете обернуть большую часть функциональности в хранимых процедурах. Описанный метод также легко сопоставляется с базой данных NoSQL.