Корней Иванович Чуковский полностью согласен с автором. Очень радует такая солидарность между современниками и стоиками русского языка. Побольше бы и почаще.
Как-то неубедительно звучит. Тормозить свой код дублированием в несколько баз из-за параноидальной боязни отвала MySQL ни кто не будет. Лучше сразу выбросить эту сферу применения из разработки, дабы не тратить свое время понапрасну =)
Чем проще то? Намного проще подключить библиотеку автора и спокойно использовать, чем взрывать себе мозг сериалайзами. А с учетом индексов вполне возможно, что и работать будет быстрей.
Поддержка множества? Насколько я знаю 2 или 3 базы всего поддерживается. А движков — десятки. Вот из этого я и сделал вывод, что включить поддержку нераспространенной БД в код phpBB весьма проблематично. И, как мне кажется, модом новую БД к форуму не прикрутишь — нужна модификация ядра. Но тут не уверен — не интересовался.
Врятли это получится. Во-первых, придется поддерживать весь функционал SQL как минимум тот, что использует php (а он его использует весьма обширно). Во-вторых придется убедить разработчиков phpBB реализовать поддержку твоей базы в коде, что весьма и весьма сомнительно.
Я бы пошел именно по пути предоставления сильно упрощенной функциональности SQL, но с максимальной оптимизацией. То есть реализовывать только самые быстрые механизмы БД. Тот же MySQL изначально был сильно урезанным и за счет этого выполнялся очень быстро, хотя и не предоставлял таких возможностей, как, например, Oracle (и сейчас не предоставляет). Тебе нужно идти темже путем, только уже по отношению к MySQL.
Смысл такой базы очевиден, если требуется реализация простейшего функционала БД. Допустим, авторизация пользователей или гостевая книга. Нагрузки мизерные, используется 2-3-4 простейших селекта/инсерта. Для этих нужд такая база идеальна и продук получается «из коробки» без танцев с бубном с MySQL даже если он на хостинге и присутствует.
А зачем нужен SQL? Ты ведь не собираешься использовать эту БД ни где кроме как в ПХП? Тогда можно обойтись удобным API. В этом случае и работать быстрее будет, поскольку SQL еще и парсить надо, что весьма накладно. Если и поддерживать SQL, то чисто в довесок, а основной упор делать на написание удобных и быстрых функций самых востребованных операций.
О, спасибо за разъяснение. Но у меня тут же возникает сопутствующий вопрос: антена любой длины собирает весь диапазон волн или чтобы собрать всю радиоэнергию нужно несколько антен, расчитанных на разный диапазон волн?
Не совсем корректно утверждение, что энергия уходит в никуда. Даже касаемо радио волн. Детектерный приемник, равно как и любой другой, получает ее не халявно — он забирает часть мощности волны. Соответственно чем больше приемников ловит «Маяк» тем мощнее должен быть его сигнал для качетсвенного приема. И вроде бы даже именно так рассчитываются рейтинги радио-теле-передач, когда вычисляют можность волны и определяют сколько людей смотрят/случают программу.
З.Ы. Я не помню откуда это узнал. Возмножно это фейк. Поправте, если я не прав.
У бытовых радиоточек вроде было свое сетевое питание — своя разетка по которой шел и сигнал и ток. Как с ним можно было внедрить такую же схему? Или ты вместо втыкания в разетку один провод подключал к батарее, а второй к руке? =)
www.litru.ru/?book=72506
Я бы пошел именно по пути предоставления сильно упрощенной функциональности SQL, но с максимальной оптимизацией. То есть реализовывать только самые быстрые механизмы БД. Тот же MySQL изначально был сильно урезанным и за счет этого выполнялся очень быстро, хотя и не предоставлял таких возможностей, как, например, Oracle (и сейчас не предоставляет). Тебе нужно идти темже путем, только уже по отношению к MySQL.
Тогда база может найти своего потребителя.
Так что труд автора далеко не напрасен.
З.Ы. Я не помню откуда это узнал. Возмножно это фейк. Поправте, если я не прав.
З.Ы. Я так понял схема с усилителем, но без батареек.
бизнесакооператива =)