Лучший способ использовать базу данных PostgreSQL в качестве простого хранилища значения ключа
Vagrantfiles - это программы на Ruby. Это помогло бы, если бы вы, по крайней мере, правильно сделали отступ. Как вы и подозревали, есть проблема с @ machine.name; проблема в том, что вы нигде не определили @machine. Если вы puts @machine, он, вероятно, покажет, что он не определен. Глядя на этот источник , который, по-видимому, там, где вы его нашли, это может быть потому, что плагин триггеров не установлен в вашей версии.
4 ответа
Другая опция состоит в том, чтобы использовать JSON или JSONB с уникальным индексом хеша на ключе.
] Если вы вынуждены использовать реляционную базу данных, то я бы предложил попробовать найти структуру в ваших данных, чтобы воспользоваться тем, что вы отказались от преимущества скорости, которую вы получили с неструктурированными данными и хранилищем значений ключей. Чем больше структура вы найдете, тем больше преимуществ вы получите из вашего затруднительного положения. Даже если вы найдете структуру только в ключах.[
] []Также подумайте, если вам нужен только последовательный или случайный доступ к вашим данным и в каком соотношении и структурировать вашу базу данных по этому требованию. Например, вы будете делать запросы к вашим значениям по типам? Каждый из этих вопросов может повлиять на то, как вы структурируете свою базу данных. [
] []Одно специфическое соображение о блобах в postgresql представлено внутри как pg_largetable (loid:oid,pageno:int4,data:bytea). Размер блоков определяется LOBBLKSIZE, но обычно 2k. Поэтому, если вы можете использовать массивы байт в вашей таблице вместо блоков и ограничивать размер пары значение/ключ под блоком, вы можете избежать этой индирекции через вторую таблицу. Вы также можете увеличить размер блоков, если у вас есть доступ к настройке базы данных.[
] []Я бы посоветовал поискать структуру в данных и шаблоны в доступе к данным, а затем задать свой вопрос еще раз с большей детализацией.[
].] Это действительно должно зависеть от того, каким будет ключ. Если это всегда будет строка меньше 255 символов, то используйте Varchar в качестве yoru PK, а затем используйте blob (предполагая большое значение) для значения. если это всегда будет число, используйте int и т.д.[
] []Другими словами, нужно больше информации, чтобы действительно дать хороший ответ :)[
].]Что вам нужно хранить в виде значения ? Строки ? Инты ? Объекты (например, сериализованные объекты Java). Простая реализация будет работать с 3-столбцовой таблицей, имеющей вид:[
] [NAME(VARCHAR) TYPE(VARCHAR) VALUE(VARCHAR)
] (возможно, ТИП - это какое-то перечисление). Вышеуказанное не сработает для двоичных данных, таких как сериализованные объекты, и, возможно, вам понадобится BLOB там.[
] [] Или же (и, возможно, [] намного [] лучшая идея), вы видели []Apache Commons Configuration[] ? Вы можете вернуть это с помощью базы данных (через JDBC), и вы можете хранить свойства так, что вы получите их таким образом:[
] [// get a property called 'number'
Double double = config.getDouble("number");
Integer integer = config.getInteger("number");
]Это может сэкономить вам много горя в плане реализации. У вас []может быть [] проблема с сохранением двоичных данных, в том, что вам придется сериализовать их перед вставкой и после извлечения. Но я использовал это в прошлом для хранения ints, doubles и сериализованных Java-объектов через XStream, так что я могу подтвердить, что это хорошо работает.[
].