Firebird для облачного приложения?
Я начну систему POS (точка продажи), которая начнется как обычная интрасеть (на начальной стадии бета-тестирования), но позже я хочу перейти на облачное предложение. Я предложу это как гибридное решение.
Я хочу, чтобы он использовал Firebird, потому что более простое развертывание, минимальная занимаемая площадь и возможность использовать встроенный многопоточный сервер. Однако я беспокоюсь, можно ли использовать firebird для облачного сервиса с отказоустойчивостью, репликацией данных и т. Д., Чтобы он был достаточно надежным, чтобы небольшие компании включили в него свой бизнес (аналогично сервису свежих книг).
Другой вариант - использовать Postgress, но у меня нет опыта работы с ним.
Достаточно ли хорош FB для использования в качестве бэкэнда SAAS? Любая успешная реализация?
PD: Я думаю о развертывании его на GoGrid или Rackspace...
4 ответа
FB - отличный вариант, он может обрабатывать большие наборы данных и имеет возможность распределять дб по нескольким файлам. Я недавно использовал его в нескольких веб-проектах на сайте inmobiapp.com. Но единственное, что мне не хватает, - это репликация, пока единственное решение, которое я использовал, называется ibpreplicator, это очень хороший представитель. инструмент, если настроен правильно. Вы можете попробовать это бесплатно, но вы должны купить лицензию.
Также рассмотрите поддержку драйверов для языка программирования, который вы будете использовать. В прошлый раз, когда я проверял, что поддержка FB на Rails не так хороша, с другой стороны, PHP имеет отличную поддержку FB.
Вы должны кодировать свое POS-приложение без каких-либо знаний о SQL-интерфейсе. Таким образом, вы можете переключать бэкэнды в любое время. Также полезно, чтобы код приложения не понимал внутренности постоянного кода, в противном случае у вас есть нарушение уровня.
Обычный способ сделать это - использовать библиотеку Object Relational Mapping (ORM). В этом FAQ Firebird рекомендуются некоторые ORM, которые работают с Firebird.
Firebird - хорошая СУБД, но, к сожалению, не очень распространенная как в веб-приложениях, так и в хостинговых компаниях.
Лично мне нравится программное обеспечение FB, но я не слишком заинтересован в сообществе вокруг него.
И заставить UTF8 работать с локализацией без учета регистра... Вот что заставило меня отказаться от этого..
Я бы порекомендовал postgres, mysql (или mariadb).
Некоторые люди все еще думают, что mysql нестабилен, у меня никогда не было проблем, но я не работал с данными размером более 1 ГБ.
Что бы вы ни выбрали, график резервного копирования.
ОБНОВЛЕНИЕ Кто-то отрицал мой ответ. Делясь своим плохим опытом с Фондом FB и, если быть точным, с H. Borrie, этот ответ не делает "бесполезным". Если отношение к авторам улучшилось, я искренне поздравляю FB.
Извините, я немного грубоват, но гибрид - это чушь собачья. Мне нравится идея SaaS POS, но не балуйте себя удовольствиями, идя по длинному и ветреному пути поддержки обслуживания программного обеспечения на месте.
Отсутствие обслуживания на месте - единственная наиболее привлекательная причина для SaaS-решения как для клиента, так и для вас!
С самого начала сделайте его чистым SaaS-приложением с надлежащей поддержкой полноэкранного браузера, упрощенным юзабилити и шифрованием SSL. Также подумайте о конкурентах, особенно Square, потому что ваша система скорее привлечет мелких торговцев, а Square повсюду.
Если вы не делаете на сайте в первую очередь, выберите правильную веб-среду и ORM с самого начала. Вы можете оптимизировать вещи позже, когда у вас есть причина и опыт для этого.
Теперь это только мое мнение, но подумайте о том, что я только что сказал, и особенно думайте об этом не только с технологической точки зрения.