Насколько всё это правдиво при использовании JDBC/ODBC? Они ведь поверх SQL*Net-а работают, значит всё тоже самое должно сработать и там или есть какие-то подводные камни?
Мне импонируют naming conventions от немецкой Trivadis AG: sdrv.ms/1fVCbAK (прошу прощения за SkyDrive, не смог сходу найти в интернете ссылку на последнюю версию). А вообще, я надеюсь, что Оракл когда-нибудь одумается и отменит это дурацкое ограничение в 30 символов, и жить стало бы намного легче.
А как же Wuala? Позволяет всё то же что и SugarSync и даже больше. Юзабилити интерфейса правда страдает, но в остальном мне кажется лучшей альтернативой.
Обычно, когда говорят «NoSQL», подразумевают partition tolerance. А здесь даже репликации нет, не то что шардинга. В целом, Oracle и MSSQL предоставляют подобный инструментарий для хранения и работы с XML, а местами и больше (ну может синтаксис не такой лаконичный), поэтому с первого взгляда не вижу никаких преимуществ, кроме цены.
MongoDB без getLastError() и без реплик ну никак не может сравниваться с PostgreSQL с fsync'ом, т.к. без этого монго не даёт никаких гарантий, что данные реально записались и не будут потеряны.
Хотел бы добавить ещё один минус: хотя инструмент и позиционирует себя как очень быстрый путь сгенерировать данные, но в особо сложных случаях (которых впринципе много для нормализованных реляционных данных) его производительность много меньше, чем использование нативных средств СУБД (PL/SQL, T-SQL, pgPL/SQL) даже с использованием различных предлагаемых «костылей» типа memstore, различных настроек транзакционности и проч.
Приходилось использовать этот инструмент для генерации чуть более чем десятка сущностей общим объёмом около 100 миллионов записей. Из-за того что сущности сильно взаимосвязаны на генерацию уходило около 6 часов, что не очень хорошо. Это всё, что можно было вытянуть из бенератора с учётом его тюнинга и преднастройки БД (отключения триггеров, констрейнтов и проч.). На PL/SQL задача заняла по-моему в 10 раз меньше времени, но т.к. нужен был инструмент, который работал бы с разными БД, то остановились на бенераторе. В целом действительно не плохо, но требует некоторого времени на изучение всех возможностей.
Думаю, что имелось ввиду не «без отключения СУБД», а «без отключения от СУБД» т.е. «без остановки приложения, на котором эта СУБД рабтает». В любом случае, изменение таблицы, из которой идёт постоянное чтение и в которую идёт постаянная запись раньше требовало экслюзивного доступа к таблице, сейчас же всё можно сделать не прекращая работу приложения.
Администраторы получают возможность производить операции связанные с сбросом схемы, добавлением или удалением столбцов данных или переименованием столбцов без отключения СУБД. Ранее подобные возможности были доступны только в NoSQL-продуктах.
Ну прямо-таки «только в NoSQL-продуктах». В той же Oracle DB и в некоторых других RDBMS есть такая возможность.
Да, выложите, пожалуйста, ещё главу. Очень интересно написано. И ещё, если можно, поделитесь полным содержанием книги, интересно какие ещё темы затронуты.
Спасибо, что в течение последних десяти лет вы являетесь нашим клиентом. В благодарность за вашу преданность мы вам дарим 3 года бесплатного сервиса. Ваше облако...
И три года ваше письмо никто не получит :). А там того и гляди и адресаты не доживут.
Sorry, we were unable to create the *** account. Our records indicate that you already own an account in the service and currently Team Foundation Service Preview only allows one account per user.
Хотя никаких аккаунтов не создавал. Поясните, пожалуйста, что бы это могло значить.
Отключите проверку орфографии в настройках и проблема с курсором исчезнет. Баг.
docs.mongodb.org/manual/replication/
И это не слух, а реальный опыт.
Мда, искренне сочувствую я тем проектам, где вы это встречали. Я лично не встречал ни одного проекта с настройкой СУБД по умолчанию.
Как бы монго без реплик тоже стабильностью не блещет, в продакшн без этого её никто ставить не будет.
Приходилось использовать этот инструмент для генерации чуть более чем десятка сущностей общим объёмом около 100 миллионов записей. Из-за того что сущности сильно взаимосвязаны на генерацию уходило около 6 часов, что не очень хорошо. Это всё, что можно было вытянуть из бенератора с учётом его тюнинга и преднастройки БД (отключения триггеров, констрейнтов и проч.). На PL/SQL задача заняла по-моему в 10 раз меньше времени, но т.к. нужен был инструмент, который работал бы с разными БД, то остановились на бенераторе. В целом действительно не плохо, но требует некоторого времени на изучение всех возможностей.
Ну прямо-таки «только в NoSQL-продуктах». В той же Oracle DB и в некоторых других RDBMS есть такая возможность.
И три года ваше письмо никто не получит :). А там того и гляди и адресаты не доживут.
Хотя никаких аккаунтов не создавал. Поясните, пожалуйста, что бы это могло значить.