Какую базу данных я должен использовать для хранения записей, и как я должен использовать ее?
Вот является пример для скрытого отделения путем:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title></title>
<style>
*[data-when-js-is-on] {
display: none;
}
</style>
<script>
document.getElementsByTagName("style")[0].textContent = "";
</script>
</head>
<body>
<div data-when-js-is-on>
JS is on.
</div>
</body>
</html>
(необходимо было бы, вероятно, настроить его для плохого IE, но Вы получаете идею.)
6 ответов
Я вижу две возможности: sqlite и BerkeleyDB. Поскольку мой вариант использования явно не относительный, я соблазняюсь пойти с BerkeleyDB, но я не действительно знаю, как я должен использовать это, чтобы хранить мои записи, так как он хранит только пары ключ / значение.
То, что вы описываете, как раз и является реляционной, даже если вам нужна только одна таблица. SQLite , вероятно, сделает это очень легко.
РЕДАКТИРОВАТЬ: Реляционная модель не имеет ничего общего с отношениями между таблицами. Отношение - это подмножество декартова произведения других множеств. Например, декартово произведение действительных чисел, действительных чисел и действительных чисел (да, все три одинаковые) дает трехмерное координатное пространство, и вы можете определить отношение в этом пространстве с помощью формулы, скажем x * y = z . каждый возможный набор координат (x0, y0, z0) либо находятся в соотношении, если они удовлетворяют данной формуле, либо нет.
Реляционная база данных использует эту концепцию с некоторыми дополнительными требованиями. Первое и самое главное, размер отношения должен быть конечным. Приведенное выше отношение произведения не удовлетворяет этому требованию, потому что существует бесконечно много 3-кортежей, удовлетворяющих формуле. Есть ряд других соображений, которые больше касаются того, что является практичным или полезным на реальных компьютерах, решающих реальные проблемы.
Лучший способ подумать о проблеме - это подумать о том, где каждый тип механизма сохранения работает лучше, чем другой. Вы уже понимаете, что реляционное решение имеет смысл, когда у вас есть много отдельных наборов данных (таблиц), которые должны поддерживать отношения между ними (ограничения внешнего ключа), что практически невозможно реализовать с помощью хранилища ключей и значений. Еще одно реальное преимущество реляционной системы заключается в том, что она делает возможными сложные специальные запросы с использованием правильных индексов. Это следствие того, что уровень базы данных действительно понимает данные, которые он представляет.
Хранилище ключей и значений имеет собственный набор преимуществ. Один из наиболее важных - способ масштабирования хранилищ ключей и значений. Это не является следствием того, что memcached , couchdb , hadoop все используют хранилище значений ключей, потому что поиск значений ключей легко распределить по нескольким серверам. Еще одна область, в которой хорошо работает хранилище «ключ-значение», - это когда ключ или значение непрозрачны, например, когда сохраненный элемент зашифрован, чтобы его мог прочитать только его владелец.
Чтобы понять эту точку зрения, хорошо работает реляционная база данных. даже если вам просто не нужно больше одной таблицы, рассмотрите следующий (не оригинальный)
SELECT t1.actor1
FROM workswith AS t1,
workswith AS t2,
workswith AS t3,
workswith AS t4,
workswith AS t5,
workswith AS t6
WHERE t1.actor2 = t2.actor1 AND
t2.actor2 = t3.actor1 AND
t3.actor2 = t4.actor1 AND
t4.actor2 = t5.actor1 AND
t5.actor2 = t6.actor1 AND
t6.actor2 = "Kevin Bacon";
, который, очевидно, использует одну таблицу:
BerkeleyDB хорош, также посмотрите воплощения * DBM (например, GDBM). Однако большой вопрос: что вам нужно искать? Вам нужно искать по этому URL-адресу, по диапазону URL-адресов или по указанным вами датам?
Также вполне возможно хранить группы записей в виде простых файлов в локальной файловой системе, сгруппированные по датам или условиям поиска и т. Д.
Ответ на вопрос «поиска» - самое большое начало.
ключ / значение, вам нужно убедиться, что сам KEY хорошо определен для ваших поисков. Если, например, вам иногда нужно искать по датам, а другим - по заголовку, вам нужно будет поддерживать строку «запись», а затем, возможно, 2 или более строк «индекса», ссылающихся на исходную запись. В хранилище ключей / значений можно смоделировать практически все.
А как насчет MongoDB ? Пока не пробовал, но кажется интересным.
Лично я бы все равно использовал sqlite. Это всегда работало для меня (и для других, с которыми я работаю). Когда ваше приложение разрастается, и вы вдруг захотите сделать что-то более сложное, вам не придется переписывать.
С другой стороны, я видел различные комментарии к списку разработчиков Python о Berkely DB, которые предполагают, что это менее чем замечательно; вы получаете доступ только в стиле dict (что, если вы хотите выбрать определенные диапазоны дат или заголовки вместо URL-адресов); и его нет даже в стандартном наборе библиотек Python 3.
Если вы собираетесь использовать только одно поле для поиска записей, хорошим выбором будет простое хранилище ключей и значений. Сохраните это отдельное поле (или любой другой уникальный идентификатор) в качестве ключа, сериализуйте каждую запись как строку (используя JSON или аналогичный) и сохраните эту строку как значение. Berkeley DB, безусловно, является разумным выбором для хранилища ключей и значений, но есть много альтернатив на выбор: http://en.wikipedia.org/wiki/Dbm
Если вы хотите искать записи по любому из нескольких полей, SQLite может быть самым простым для целей разработки. Вы будете писать запросы на SQL, но вам не придется поддерживать сервер базы данных. Все механизмы с несколькими ключами уже написаны для вас.
Если вы действительно хотите избежать использования SQL или выжать максимум производительности из своего хранилища данных, и вам нужен доступ с несколькими ключами, рассмотрите возможность слой дополнительной логики поверх хранилища ключей и значений. Можно построить поведение, подобное столбцу, поверх хранилищ ключей и значений путем сериализации ваших записей и вставки значений «столбцов» каждой записи в качестве дополнительных ключей, значения которых содержат «первичный» ключ вашей записи. (Вы' Мы эффективно используем хранилище «ключ-значение» как словарь записей и словарь индексов для поиска этих записей.) Google App Engine делает нечто подобное. Вы можете сделать это самостоятельно или использовать одну из различных документно-ориентированных баз данных, которая сделает это за вас. Для интересного чтения попробуйте поискать в Google "nosql". http://www.google.com/search?&q=nosql
Хорошо, вы говорите, что просто сохраняете данные ..? Вам действительно нужна БД только для поиска, поиска, суммирования и т. Д. Итак, для хранения просто используйте простые текстовые файлы и добавьте строки. Сжимайте данные, если вам нужно, используйте разделители между полями - почти любой язык сможет читать такие файлы. Если вы все же хотите получить, то сосредоточьтесь на своих потребностях в поиске, по дате, по ключу, по каким ключам и т. Д. Если вам нужна простая клиентская сторона, тогда вам нужен простой клиентский БД. SQLite намного проще, чем BDB, но посмотрите на такие вещи, как Sybase Advantage (очень быстро и бесплатно для локальных клиентов, но не с открытым исходным кодом) или VistaDB или firebird ... но все это потребует локальной конфигурации / настройки / обслуживания. Если вы выберете локальный XML для «значительного» количества записей, вы получите излишне раздутые размеры файлов ...!