Юрий Ярош
> в PostgreSQL и в Oracle тоже есть поддержка любых типов
работа с JSON или XML это как раз таки выходит за рамки возможностей традиционной реляционной БД. В стандарт SQL даже добавили новые функции для работы с тем же XML, не говоря уже о том, что напихали в свои СУБД различные вендоры. В конкретных СУБД могут быть и более экзотические типы данных, это нормально, т.к. производители удовлетворяют потребности клиентов. Тот же постгрес в свое время приобрел некоторые черты объектно-ориентированных баз за счет поддержки OID.
> Эм... "реляционность" MongoDB это следствие использования B-tree в качестве индекса
совершенно не понимаю как "реляционность" (пусть даже в кавычках) следует из использования B-дерева как и любого другого типа индекса. Используя индексы вы находите физическое расположение данных быстрее (значительно), чем делали бы это последовательным поиском, и не более. Это позволяет, имея значение индексированнного поля (например, id), вытащить всю остальную запись (документ, объект, etc). Как это делает базу реляционной?
> монга не ACID в общем понимании MVCC - нет полноценной атомарность и изоляции операций
да, пожалуй это так. Насчет инвестиций могу ошибаться, но кажется их привлекали, показывая систему с надежно работающей репликацией "из коробки" (разумеется за счет снижения гарантий ACID) и прочими вещами, более проблемными для РСУБД.
> Так что наличие SQL в монге угробило бы её как OpenSource продукт.
Я даже не ожидал, что вы попытаетесь объяснить это с точки зрения маркетинга. Я пытался вам показать, что он там совершенно не к месту, т.к. разрабатывался для реляционных систем.
Извините, я пока не понял почему монга - реляционная СУБД
Юрий Ярош
> Mongo key-value ?
Я имел в виду NoSQL. Не люблю этот термин, он слишком общий и неточный, хотя конкретно тут подходит. Я изменю ответ.
> Вообщем-то монга так же реляционна как и MySQL
хм, ну Си тоже тогда объектно-ориентированный язык, почти такой же как C++, потому что в Си есть указатели на функции и ими можно запилить полиморфизм.
Вас не смущает хотя бы то, что первая нормальная форма требует работы с атрибутами как с атомарными значениями, в то время как Монга имеет first-class поддержку иерархических структур? Ссылки становятся лишь одним из вариантов связей между документами.
Ну и вообще, если бы Монга была реляционной БД настолько, насколько постгрес, ей бы стоило реализовать поддержку SQL. Делать реляционную базу без поддержки SQL на сегодняшний день - убить проект в самом начале.
hidden_pingvin а потому что врядли вы будете искать что-то внутри состояния игры. Вам состояние нужно целиком, как черный ящик, и искать вы его будете по какому-то простому ключу (id игры или id игроков + время начала игры). Для таких задача РСУБД - оверхед. Само состояние наверняка будет сложным и структурированным, и все равно вы прийдете к хранению его в какой-нибудь JSON-колонке. А тогда смысл брать РСУБД?
Вот статистика - совсем другое дело. Там будут поиски/свертки/отчеты и т.д., там пригодится.
Ничего толком не понятно. Что вы хотите сохранить в базе об атрибуте? На какой сущности от висит? Его тип? Параметры? Что собираетесь искать? Зачем вам IN сейчас, как вы им польузетесь?
Jentoss
> PHP-шники-выскочки
Ключевое слово тут - "выскочки". У меня конечно есть определенные претензии к PHP (у кого их нет :) ), но они не имеют ничего общего с претензиями к людям, над которыми PHP играет злую шутку, создавая иллюзию, что за месяц можно полностью погрузиться в мир промышленной разработки. Если к вам это не относится - спокойно идите дальше.
stanlee и я подразумеваю выкладку - я ж и говорю, что нужно вытаскивать пакеты еще при сборке на CI-сервере, а не при деплое. Я могу упускать что-то специфичное для bower-а (нечасто с ним сталкиваюсь), но принципиальных отличий от того же npm или какого-нибудь nuget я не вижу. Это общий принцип, детали зависят от вашего софта для CI и вашего проекта.
Давайте тут и обсуждать, я постараюсь почаще просматривать страницу.
zakar1ya как раз это тот кейс, когда триггеры пожалуй пригодятся. Что вы понимаете под зависимостью? То, что одно поле всегда можно вычислить на основе значений других полей?
> как вообще будет одновременно работать сразу 2 сервера например?
Здесь я имел в виду два железных/виртуальных сервера, т.е. две разные машины. Теоретически конечно можно настроить и две экземпляра веб-сервера на одной машине, возможно это подойдет для вашего сценария с деплоем. Но устойчивости к сбоям это прибавит немного. Обычно, если простой во время деплоя достаточно критичен, то уж тем более критичен простой из-за поломки сервера, и поэтому сразу заботятся о проблеме дублирования серверов и распределения нагрузки.
Само собой, вам нужно будет продумать механизмы исключения серверов из ротации, чтобы тот же nginx не пытался передать запрос к серверу, который сейчас деплоится и который трогать нельзя.
Vlad Harbarchuk
> TypeScript :)
вполне себе решение, только тогда получается что JS - это какой-то промежуточный язык. Потому я и обрадовался WebAssembly - сколько можно мучать JS, минифицировать его и uglify-ить.
Vlad Harbarchuk
> ну так для клиентской разработки есть js \ фронтенд разработчики
вы так говорите будто это рабы какие-то)). Ну вот кстати и объяснили, почему среди фронтендеров так много молодых людей - 70-80% это те, кто сразу начал JS и ему стало хорошо. Только это какое-то неправильное направление развития технологий - если я хочу стать фронтендером, значит мне надо полностью переосмыслить мои умения по моделированию мира? Или нужно на государственном уровне поддерживать нужную концентрацию JS-разработчиков, чтобы было кому делать фронтэнд?))
Если б это "переосмысление" было нужно для работы с каким-нибудь искусственным интеллектом (как было, когда создавали Пролог) - тогда другое дело, но для анимирования многострадальных div-ов и span-ов это как-то слишком).
Идеальный выбор - это когда язык подбирается по конкретной задаче+мышлению разработчика (как сейчас на дотнете - есть ООП-шный C#, есть более функциональный F#, есть даже IronPython), но уж никак не под целевую платформу (неважно - аппаратную или виртуальную).
> играет злую шутку с теми, кто уже знает несколько языков
куда более злую шутку он играет с менеджерами проектов, которые считают, что можно тех же людей, что делали десктопный клиент пару лет назад, приспособить для разработки веб-клиента. И они искренне не понимают, почему это невозможно. Я вот в принципе тоже не понимаю, как мы к этому пришли)). Брать других людей и переписывать клиент почти заново - это такое было в 60-х годах с операционными системами, до того как придумали Си и ядра ОС писались на асме - приходилось переписывать почти все заново для поддержки новой архитектуры.
Vlad Harbarchuk
Но эти попытки писать "java-style" в JS напоминают как человек из винды переходит на мак
действительно, но человека, вероятно, никто не заставлял перейти нам мак (ну мне не встречались такие случаи, что кто-то бы это делал вынужденно), если ему удобно - он останется на винде. А с JS выбора как бы и нет. Точнее он есть только за счет compile-to-js языков.
Поэтому я и говорю, что у js сейчас роль ассемблера для веба: не РАЗРАБОТЧИК выбирает этот язык, его выбрали за разрабочтика случай и история. Это все равно что под десктоп или на бэкенде нужно было бы разрабатывать на асме под конкретную аппаратную платформу, а не на любимом ОО/функциональном/процедурном языке. Конечно, сравнение на совсем точное - JS гораздо более высокоуровневый язык (даже слишком высокоуровневый - проекты asm.js и WebAssembly это подтверждают), и как бы можно разрабатывать непосредственно на нем, но если тебе в нем что-то не подходит - ситуация с ассемблером повторяется.
Я вот к тому же не перевариваю динамические языки. Просто не в состоянии их нормально использовать. Для меня отсутствие таких базовых проверок на стадии компиляции, как проверка типов - сущий адъ. Мне нужно хорошенько выспаться, чтобы суметь написать адекватный код на динамическом языке, и не накосячить. И это вопрос уже куда более серьезный, чем прототипное vs классовое ООП. Что же мне делать с JS?
