База данных SQL переполнена, если ваши потребности в хранилище малы. Когда я был молод и немой, я использовал текстовый файл и flock(), когда мне нужно было получить к нему доступ. Это не масштабируется, но я все еще чувствую, что решения без базы данных полностью игнорируются в Web 2.0.
Кто-нибудь не использует базу данных SQL для хранения? Каковы альтернативы?
Существует много альтернатив. Но имея SQLite, который дает вам силу SQL в сочетании без суеты файлового хранилища, нет необходимости искать эти альтернативы. SQLite достаточно лёгкий, чтобы его можно было использовать в сотовых телефонах и MP3-плеерах, поэтому я не вижу, как это можно считать излишним.
Поэтому, если ваше приложение не нуждается в чем-то очень конкретном, не беспокойтесь. Большинство альтернатив намного сложнее в использовании и имеют меньшую производительность.
Это просто плоский файл, содержащий полную базу данных SQL. Вы можете запрашивать, обновлять, вставлять, удалять, в процессе инсталляции практически нет накладных расходов, и все, что вам нужно, это драйвер (который входит в стандартную версию PHP)
SQLite - это программная библиотека, которая реализует автономный, безсерверный, нулевой конфигурации, транзакционный механизм СУБД SQL.
Как странно, что никто уже не упоминал об этом?
CouchDB (http://couchdb.apache.org/index.html) - это база данных, отличная от sql, и, похоже, сегодня это популярный проект, а также Google bigtable, или GT.M(http://sourceforge.net/projects/fis-gtm), который был навсегда.
База данных объектов также изобилует; dbforobjects (http://www.db4o.com/), ZODB (http://www.zope.org/Products/StandaloneZODB), просто чтобы назвать несколько.
Все они предположительно быстрее и проще традиционных баз данных SQL для определенных случаев использования, но никто не подходит к простоте плоского файла.
Распределенная хеш-таблица, например google bigtable или hadoop - простая и масштабируемая база данных без SQL и часто подходит для сайтов гораздо лучше, чем база данных SQL. SQL отлично подходит для сложных реляционных данных, но на большинстве веб-сайтов этого требования нет. Большинство веб-сайтов хранят и извлекают данные в нескольких формах и не требуют выполнения сложных операций с данными.
Взгляните на одно из этих решений, поскольку они предоставят вам все необходимые параллельные возможности, но не согласуются с традиционными идеями нормализации данных. Их можно считать довольно похожими на кучу названных текстовых файлов.
Вероятно, это зависит от того, насколько динамичен ваш веб-сайт. Я использовал wiki-программное обеспечение, когда использовал RCS для проверки и удаления текстовых файлов. Я бы не рекомендовал это решение для чего-то, что получает столько обновлений, как StackOverflow или Wikipedia. Что касается базы данных, так это то, что они хорошо масштабируются, и авторы движка базы данных выяснили все незначительные детали одновременного доступа, балансировки нагрузки, репликации и т.д.
Я бы не выбрал, использовать ли SQL-базу данных на основе того, сколько данных я хотел бы хранить, - я бы выбрал, основываясь на том, какие данные я хотел хранить и как их использовать.
Wikipeadia определяет базу данных следующим образом: База данных представляет собой структурированный набор записей или данных, которые хранятся в компьютерной системе. И я думаю, что ваш ответ кроется там: если вы хотите хранить такие записи, как учетные записи клиентов, права доступа и т.д., Тогда база данных, такая как mySQL или SQLite или что-то еще не переполняет. Они дают вам проверенный и надежный механизм управления этими записями.
Если, с другой стороны, ваш сайт хранит и предоставляет неизменный контент на основе файлов, такой как PDF файлы, отчеты, mp3 файлы и т.д., то просто хранить их в определенном макете каталога на диске более чем достаточно. Я бы также включил XML-документы здесь: если у вас был, например, производственный отдел, который создал статьи для веб-сайта в формате XML, нет необходимости помещать их в БД - хранить их на диске и использовать XSLT для их доставки.
Ваш выбор SQL или нет также будет зависеть от того, как будет загружен контент, который вы хотите сохранить. SQL, очевидно, хорош для извлечения многих записей на основе критериев поиска, тогда как дерево каталогов, база данных XML, база данных RDF и т.д. С большей вероятностью будут использоваться для извлечения отдельных записей.
Выбор механизма хранения очень важен, когда вы пытаетесь масштабировать сайт с высоким трафиком и заполнять все в SQL DB быстро станет узким местом.
Я бы сказал, что это не зависит от того, хранишь ли вы меньше или больше информации, это зависит от того, как часто вы запрашиваете сохраненные данные. Производители баз данных превосходны в кэшировании запросов, поэтому они часто лучше подходят для выбора. Однако, если вам не нужна динамическая веб-страница и просто загружаете статические данные - возможно, текстовый файл является лучшим вариантом. Какой формат данных хранится (например, XML, JSON, key = pair) не имеет значения - это операции ввода/вывода, которые являются тяжелыми по производительности.
Когда я занимаюсь разработкой веб-приложений, я всегда использую RDBMS в качестве основного держателя данных. Если веб-приложение не нужно обслуживать динамические данные при каждом запросе, я просто применяю функцию кеша, хранящую данные в файле кеша, который запрашивается, когда новые данные не были добавлены в первичный источник данных (РСУБД).
Это зависит от того, что вы храните. Мой блог использует Blosxom (написанный на Perl, но аналогичная вещь может быть сделана для PHP), где каждая отдельная запись представляет собой отдельный текстовый файл. Первая строка - это простой текст (заголовок), а остальная часть - неограниченный HTML. Следуя нескольким простым правилам, они визуализируются, чтобы сформировать простую, но эффективную структуру ведения блога.
У этого есть недостатки, но это также означает, что каждый пост является дискретным файлом, который хорошо работает для обновления на локальном компьютере, а затем публикуется на удаленном веб-сервере. Это ограниченно, когда дело доходит до эффективного опроса, хотя, конечно, это не очень хороший выбор, если вы хотите получить тонкое управление и веб-взаимодействие с вашими данными.
Отметьте CouchDB.
Я использовал LINQ to XML в качестве источника данных в .NET-проекте. Это было небольшое решение и использовало кеширование для снижения проблем с производительностью. Я бы сделал это снова для быстрого сайта, который просто должен хранить данные в общем месте без увеличения требований к серверу.
Зависит от того, что вы храните и как вам нужно получить к нему доступ. Как правило, sql обеспечивает отличную отчетность и возможность управления вручную. Почти все требует определенного способа управления тем, что хранится и сообщать об этом.
На одном уровне с базами данных SQL есть ISAM (метод индексированного последовательного доступа) - в основном таблицы и индексы, но без SQL и no явные отношения между таблицами. Пока концептуальная основа соответствует вашему дизайну, она будет хорошо масштабироваться. Я использовал Codebase эффективно в течение длительного времени.
Если вы хотите работать с данными типа SQL-базы данных, рассмотрите FileMaker.
В Perl я использую DBM или Storable для таких задач. DBM будет автоматически обновляться при обновлении переменной.
Простой ответ заключается в том, что вы можете использовать любой формат хранения данных, от стандартного, до базы данных (который обычно связан с протоколом), даже на заказ в формате файла.
Есть компромиссы для каждого выбора, который вы делаете в ИТ, и, конечно же, сайты ничем не отличаются. В начале 2000 года файловые системы форума были популярны, так как они позволяют любому, у кого есть ограниченная техническая возможность редактировать страницы и сообщения. Полностью статические сайты быстро становятся неуправляемыми, а контент не получает преимуществ от обновления до пользовательского интерфейса сайта; однако сайт, если он правильно закодирован, может быть просто перемещен в подкаталог или разорван в новый дизайн. CMS и динамические системы приносят с собой собственный набор проблем, а именно, что еще нет широко распространенного стандарта для хранения данных среди них; что они часто полагаются на сторонние плагины, чтобы предоставлять функции между стилями дизайна (несмотря на их документацию, защищающую разделение функции и формы).
В 2016 году довольно редко не использовать стандартный механизм хранения, такой как * SQL RDBMS; хотя статические генераторы сайтов, такие как Jekyll (обладает большим количеством страниц GitHub); и независимые игроки, такие как октябрьская CMS, по-прежнему предоставляют статическое файловое хранилище.
Мое личное предпочтение заключается в использовании RDBMS с поддержкой SQL *, он предоставляет мне синтаксис, который стандартизирован, по крайней мере, на уровне поставщика, знакомый и мощный синтаксис, но, в отличие от многих людей, я не думаю, что это единственный способ, и в большинстве случаев будет выступать за использование сайта-генератора для сохранения частей, которые не должны быть динамическими для статического магазина, поскольку это самый дешевый способ жить в Интернете.
TL;DR; это зависит от вас, поддержка SQL и RDBMS является популярной.
Я бы посмотрел XML, если бы я был вами. См. w3schools Раздел XML-учебника на левой стороне. Тонны возможностей без использования базы данных SQL.