База данных SQL переполнена, если ваши потребности в хранении малы. Когда я был молод и немой, я использовал текстовый файл и flock(), когда мне нужно было получить к нему доступ. Это не масштабируется, но я все еще чувствую, что решения без базы данных полностью игнорируются в Web 2.0.Каковы альтернативы хранению базы данных SQL для веб-сайта?
Кто-нибудь не использует базу данных SQL для хранения? Каковы альтернативы?
Существует много альтернатив. Но имея SQLite, который дает вам силу SQL в сочетании без суеты файлового хранилища, нет необходимости искать эти альтернативы. SQLite достаточно лёгкий, чтобы его можно было использовать в сотовых телефонах и MP3-плеерах, поэтому я не вижу, как это можно считать излишним.
Так что, если вашему приложению не требуется что-то очень специфическое, не беспокойтесь. Большинство альтернатив намного сложнее в использовании и имеют меньшую производительность.
Я бы посмотрел XML, если бы был вами. См. Раздел w3schools раздел «Учебник XML» на левой стороне. Тонны возможностей без использования базы данных SQL.
Возможно, это зависит от того, насколько динамичен ваш веб-сайт. Я использовал wiki-программное обеспечение, когда использовал RCS для проверки и удаления текстовых файлов. Я бы не рекомендовал это решение для чего-то, что получает столько обновлений, как StackOverflow или Wikipedia. Дело в том, что они хорошо масштабируются, и авторы баз данных вычислили все незначительные детали одновременного доступа, балансировки нагрузки, репликации и т. Д.
Распределенная хеш-таблица, такая как google bigtable или hadoop, является простой и масштабируемой базы данных не SQL и часто подходит для сайтов гораздо лучше, чем база данных SQL. SQL отлично подходит для сложных реляционных данных, но на большинстве веб-сайтов этого требования нет. Большинство веб-сайтов хранят и извлекают данные в нескольких формах и не требуют выполнения сложных операций с данными.
Посмотрите на одно из этих решений, поскольку они предоставят вам все необходимые параллельные возможности, но не согласуются с традиционными идеями нормализации данных. Их можно считать довольно похожими на кучу названных текстовых файлов.
+1 вообще верно, но тогда, если кто-то обеспокоен, этот SQL переполнен, и BigTable будет мега-overkill. – vartec
@ Halil ...zgür Я не думаю, что это так. Легкий подход - это то, что требует только файла include, сохраняет его данные в простых структурах и может извлекать его без использования SQL. Предположим, вы хотите сохранить только одну структуру, кортеж с идентификатором и именем, для максимум 200 элементов. SQL и BigTable оба переполнены. –
Должен сказать, мне нравится http: //morris.github.io/microdb/Это выглядит намного проще, чем sqlite или bigtable, так как вам не нужно определять какую-либо объектную модель. –
Я бы сказал, что это не зависит от того, хранишь ли вы меньше или больше информации, это зависит от того, как часто вы запрашиваете сохраненные данные. Производители баз данных превосходны в кэшировании запросов, поэтому они часто лучше подходят для выбора. Однако, если вам не нужна динамическая веб-страница и просто загружаете статические данные - возможно, текстовый файл является лучшим вариантом. В каком формате хранятся данные (например, XML, JSON, key = pair), это очень тяжелые операции ввода-вывода.
Когда я занимаюсь разработкой веб-приложений, я всегда использую РСУБД в качестве основного держателя данных. Если веб-приложение не нужно обслуживать динамические данные при каждом запросе, я просто применяю функцию кеша, хранящую данные в файле кеша, который запрашивается, когда новые данные не были добавлены в первичный источник данных (РСУБД).
Проверить CouchDB.
CouchDB (http://couchdb.apache.org/index.html) - это база данных, отличная от sql, и, похоже, это популярный проект в наши дни, а также большой стол Google или GT.M (http://sourceforge.net/projects/fis-gtm), который существует навсегда.
База данных объектов также изобилует; dbforobjects (http://www.db4o.com/), ZODB (http://www.zope.org/Products/StandaloneZODB), просто чтобы назвать несколько.
Все они предположительно быстрее и проще, чем традиционные базы данных SQL для определенных случаев использования, но никто не подходит к простоте плоского файла.
ZODB чаще всего используется с РСУБД в качестве уровня хранения, поэтому я не уверен, что это хороший пример. Это больше похоже на ORM. – vartec
ORM тесно связан с идеей реляционного back-end. ZODB нет. Он был спроектирован как база данных объектов с подключаемым хранилищем. Я стою рядом с моим выбором. ; o) – vezult
Я использовал LINQ to XML в качестве источника данных в .NET-проекте. Это было небольшое решение и использовало кеширование для снижения проблем с производительностью. Я бы сделал это снова для быстрого сайта, который просто должен хранить данные в общем месте без увеличения требований к серверу.
SQLite изобретается для этого.
Это просто плоский файл, содержащий полную базу данных SQL. Вы можете запросить, обновление, вставка, удаление, там практически нет накладных расходов в установке и все, что вам нужно, это водитель (которая поставляется в PHP)
SQLite является библиотекой, которая реализует автономный, бессерверную , нулевой конфигурации, транзакционной базы данных SQL.
Вроде странно, что об этом никто не упоминал?
SQLLite в настоящее время является лучшим голосованием ... – cjk
Зависит от того, что вы храните и как вам нужно получить к нему доступ. Как правило, sql обеспечивает отличную отчетность и возможность управления вручную. Почти все нуждается в некотором способе управления тем, что хранится и сообщать об этом.
Это зависит от того, что вы храните. Мой блог использует Blosxom (написанный на Perl, но аналогичная вещь может быть сделана для PHP), где каждая отдельная запись представляет собой отдельный текстовый файл. Первая строка - это простой текст (заголовок), а остальная часть - неограниченный HTML. Следуя нескольким простым правилам, они создаются в простой, но эффективной структуре ведения блога.
У этого есть недостатки, но это также означает, что каждое сообщение представляет собой дискретный файл, который хорошо подходит для обновления на локальной машине, а затем для публикации на удаленном веб-сервере. Это ограниченно, когда дело доходит до эффективного опроса, хотя, конечно, это не очень хороший выбор, если вы хотите получить тонкое управление и веб-взаимодействие с вашими данными.
Я бы не стал выбирать, использовать ли SQL-базу данных в зависимости от того, сколько данных я хотел бы хранить - я бы выбрал на основе какой вид данных, которые я хотел хранить и как их использовать.
Wikipeadia определяет базу данных как: База данных представляет собой структурированный набор записей или данных, которые хранятся в компьютерной системе. И я думаю, что ваш ответ кроется там: если вы хотите хранить такие записи, как учетные записи клиентов, права доступа и т. Д., Тогда база данных, такая как mySQL или SQLite или что-то еще не переполняет. Они дают вам проверенный и надежный механизм управления этими записями.
Если, с другой стороны, ваш сайт хранит и сохраняет неизменный контент на основе файлов, такой как PDF-файлы, отчеты, mp3-файлы и т. Д., То просто хранить их в хорошо определенном макете каталога на диске более чем достаточно. Я бы также включил XML-документы здесь: если у вас был, например, производственный отдел, создавший статьи для веб-сайта в формате XML, нет необходимости размещать их в БД - хранить их на диске и использовать XSLT для их доставки.
Ваш выбор SQL или нет также будет зависеть от того, как должен быть загружен контент, который вы хотите сохранить. SQL, очевидно, хорош для получения многих записей на основе критериев поиска, тогда как дерево каталогов, база данных XML, база данных RDF и т. Д., Скорее всего, будут использоваться для извлечения отдельных записей.
Выбор механизма хранения очень важен, когда вы пытаетесь масштабировать сайт с высоким трафиком и набивать все в базу данных SQL, быстро станет узким местом.
Один уровень из баз данных SQL - это ISAM (Indexed Sequential Access Method) - в основном таблицы и индексы, но не SQL и не имеют явных связей между таблицами. Пока концептуальная основа соответствует вашему дизайну, она будет хорошо масштабироваться. Я использовал Codebase эффективно в течение длительного времени.
Если вы хотите работать с данными типа SQL-базы данных, рассмотрите FileMaker.
В Perl для таких задач я использую DBM или Storable. DBM автоматически обновится при обновлении переменной.
Простой ответ заключается в том, что вы можете использовать любой формат хранения данных, от стандартного значения, до базы данных (который обычно связан с протоколом), даже на заказный формат.
Есть компромиссы для каждого выбора, который вы делаете в ИТ, и, конечно же, сайты ничем не отличаются. В начале 2000-х годов файловые форумы были популярны, так как они позволяют любому человеку с ограниченными техническими возможностями редактировать страницы и сообщения. Полностью статические сайты быстро становятся неуправляемыми, а контент не получает преимуществ от обновления до пользовательского интерфейса сайта; однако сайт, если он правильно закодирован, может быть просто перемещен в подкаталог или разорван в новый дизайн. CMS и динамические системы приносят с собой свой собственный набор проблем, а именно, что еще нет широко распространенного стандарта для хранения данных среди них; что они часто полагаются на сторонние плагины, чтобы предоставлять функции между стилями дизайна (несмотря на их документацию, защищающую разделение функции &).
В 2016 году довольно редко не использовать стандартный механизм хранения, такой как * SQL RDBMS; хотя статические генераторы сайтов, такие как Jekyll (обладает большим количеством страниц GitHub); и независимые игроки, такие как октябрьская CMS, по-прежнему обеспечивают статическое файловое хранилище.
Мое личное предпочтение заключается в использовании RDBMS с поддержкой SQL *, это дает мне синтаксис, который стандартизирован по крайней мере на уровне поставщика, знакомый и мощный синтаксис, но, в отличие от многих людей, я не думаю, что это единственный и в большинстве случаев будет выступать за использование сайта-генератора для сохранения частей, которые не должны быть динамическими для статического магазина, поскольку это самый дешевый способ жить в Интернете.
TLDR; это зависит от вас, SQL & Поддержка RDBMS популярна.
99% времени есть лучшие альтернативы xML, поддерживаемые в языке ... для php, я бы использовал var_export/eval, поэтому мне не нужно разбирать что-либо. –
Что не так с XML? Если он хочет хранить данные, а использование базы данных немного переборщило, я бы подумал, что XML идеально подойдет. –
Проблема с XML заключается в том, что он не масштабируется, вы получаете точно такую же проблему, что и с текстовым файлом. – ilivewithian