Для сравнения иконки в среднем занимаю 500-700 байт,
влезают в inode, и как результат считываются за раз вместе с атрибутами файла.
В BeOS растровые иконки занимали 1280 байт.
В Viste иконки могут занимать до 80 кило.
SVG иконки в ZETA сжатые достигают 2-10 кило.
Статья отличная!
А насчёт нереляционных баз, так они ещё старше чем реляционные.
Да, несомненно, у хешей и B-tree скорость отличная.
Однако создавая более менее сложную систему вы неприменимо придёте к реляционности.
Вот посмотрите пример создание клона Twitter на Redis, уже с первых строк пошла реляционность, конечно это потому что такая задача, но ведь большинство именно таких.
А поиск по разным полям?
Тут конечно документо-ориентированные базы рулят по сравнению с простыми ключ-значение,
но в них появляется надобность создавать индексы =)
В общем, нереляционные базы быстры, но они не панацея, и следует обдумано подходить к вопросу, даже не смотря что это так модно нынче.
Просто если посмотреть shootout.alioth.debian.org то Lua много где показывает себя с хорошей стороны.
У всех языков свои сильные/слабые стороны, и суть в том чтобы грамотно заиспользовать только все плюсы :)
И здесь как нельзя кстати возможности встраиваемости одного языка в другой.
Нереалиационные БД хороши и быстры,
однако реалицонность можно сделать нормально только с РСУБД.
Хорошо что есть и те, и те :)
А ещё лучше то, что есть такие как MySQL и TokyoCabinet
влезают в inode, и как результат считываются за раз вместе с атрибутами файла.
В BeOS растровые иконки занимали 1280 байт.
В Viste иконки могут занимать до 80 кило.
SVG иконки в ZETA сжатые достигают 2-10 кило.
В другом случае ответ многих — ZFS :)
Графы: кодовые деревья по Хаффману
Визуализация: часы «Синхрон»
А насчёт нереляционных баз, так они ещё старше чем реляционные.
Да, несомненно, у хешей и B-tree скорость отличная.
Однако создавая более менее сложную систему вы неприменимо придёте к реляционности.
Вот посмотрите пример создание клона Twitter на Redis, уже с первых строк пошла реляционность, конечно это потому что такая задача, но ведь большинство именно таких.
А поиск по разным полям?
Тут конечно документо-ориентированные базы рулят по сравнению с простыми ключ-значение,
но в них появляется надобность создавать индексы =)
В общем, нереляционные базы быстры, но они не панацея, и следует обдумано подходить к вопросу, даже не смотря что это так модно нынче.
вот тот же ДССП уникальный по своей сути язык, но сообщество совершенно к нему равнодушно.
Как он?
У всех языков свои сильные/слабые стороны, и суть в том чтобы грамотно заиспользовать только все плюсы :)
И здесь как нельзя кстати возможности встраиваемости одного языка в другой.
однако реалицонность можно сделать нормально только с РСУБД.
Хорошо что есть и те, и те :)
А ещё лучше то, что есть такие как MySQL и TokyoCabinet
Почему не понравилось?
namespace любой может быть :)
оглянитесь их много!
А знаете среди них есть даже свободные и открытые :)