Потыкал этот ваш node.js

[OtherSide]

Стартапы для тех кто несмотря ни на что готов рисковать. Это другая атмосфера/уровень ответственности/погружение в продукт/другое развитие персонажа ну и конечно надежда на большой экзит.

Это все для фаундера. Для персонала только головняк.

Плюс вы как то сильно обобщаете по технологиям. У стартапов разные технологии, разные возиожности рынка труда везде и т.д. Конкретно в москве проще и дешевле найти фулстек на шарпе разраба, чем на ноде.

[stenking]

Это все для фаундера. Для персонала только головняк.

У фаундера 25% компании, значительные инвестиции и нет зарплаты или очень небольшая. У команды 1-2% и зарплата меньше чем в ентерпрайзе. Головняк у всех.

[OtherSide]

Это все для фаундера. Для персонала только головняк.

У фаундера 25% компании, значительные инвестиции и нет зарплаты или очень небольшая. У команды 1-2% и зарплата меньше чем в ентерпрайзе. Головняк у всех.

У фаундера есть и другие преференции
1) Он реализовывает свою мечту и амбиции
2) Если не получится - получит хотя бы опыт, все зависит от него; для персонала - лотерея
3) Ну и просто есть возможность тупо кинуть (законно или нет)

[stenking]

Это все для фаундера. Для персонала только головняк.

У фаундера 25% компании, значительные инвестиции и нет зарплаты или очень небольшая. У команды 1-2% и зарплата меньше чем в ентерпрайзе. Головняк у всех.

У фаундера есть и другие преференции
1) Он реализовывает свою мечту и амбиции
2) Если не получится - получит хотя бы опыт, все зависит от него; для персонала - лотерея
3) Ну и просто есть возможность тупо кинуть (законно или нет)

Ну вот а между этими 2-мя полюсами ( solo founder и ентерпрайс ) и находятся остальная команда . Кто-то получит хороший опыт для открытия своей компании в будущем ( я например "учился" 10 лет ), кто-то просто не готов к идее всё или ничего а предпочитает умеренный риск и т.д, кому-то просто интересно - всё таки стартапы часто делают очень крутые вещи.

И кроме преференций у фаундеров есть стресс и страх потерять свои лайфсейвинг. Т.е фаундер это скажем человек который инвестирует миллион в компанию ( как и живые деньги, так и недополученные ). У него самый большой риск. Потом идёт инвестор который тоже даёт миллион но с меньшим риском - сейчас практически не инвестируют без product market fit. Потом первая волна команды где каждый скажем недополучает 100К. Потом вторая волна где каждый уже недополучает скажем 10К. Потом третья волна где риска уже нет совсем.

Т.е. нет такого что бы белое или чёрное. Вы сами можете выбрать себе уровень риска. От фаундера и кофаундера до емплои последних волн. А дальше уже стартап становится нестартапом.

[fleshold]

А как сейчас вопрос о скрещивании бульдога и носорога SQL и noSQL? Помнится лет семь назад говорили об этом https://queue.acm.org/detail.cfm?id=1961297 , конференции там всякие, на форумах писали. Автор статьи в ту пору архитектор MS SQL Server, сейчас вроде в FB. Сорри, если вопрос глупый, давно уж не касаюсь этой области, чисто ради интереса.

[alex_127]

Эрик мужик классный но никогда тру архитектором в Mssql не был. Он занимался моделированием данных и их представлением что в основном лежало между connectivity in Mssql и languages(visual studio). Они шиппились с обоими продуктами но например я не помню чтобы хоть раз поменяли то как engine работает.

[Vladimir Kr.]

это называется альтернативно думаете. Там где нужно foreign keys - в nosql их просто нет, но надо всем об'яснить что они не нужны, атомарности транзакций тоже - "порешаем в коде"!
я не говорю, что все это плохо - но все это "узкоспециализированный инструмент".

Да, именно так. Порешаем в коде. В большенстве случаев foreign keys просто не нужны. В традиционных базах вы бы бы имели таблицы: article, author, journal, comment, article_author, article_journal, article_comment, article_revision, article_reviewers....etc... а в монге свалите в одну коллекцию. И когда вам нужно будет посмотреть сколько статей написал автор вы напишите одну строчку кода. Так же с атомарностью которой обычно достаточно в одном документе - https://docs.mongodb.com/manual/tutoria ... perations/

Ну и т.д. Все эти вещи дают более простой код, более понятную структуру данных которую удобно гонять через API, быстрые операции, отличный скелинг и многое чего.

Порешаем в коде.

Все эти вещи дают более простой код

Как это может уживаться вместе?

кластерная атомарность, мы ведь про кластер а не сингл, это не

model-data-for-atomic-operations

а вот это:
https://docs.mongodb.com/manual/referen ... e-concern/ -- это появилось в монге 2 года назад
что мы здесь видем:
надо явно указывать количество реплик, тоесть зявленная атомарность будет не на все копии существующие в кластере, а только на указанное количество. Количество надо указывать на каждой операции сохранения.
Еще раз: Монго явно утверждает - данные не будут гарантированно консистентны на всех копиях в кластере если вы не укажите количество копий ("deployment" nodes) во время каждого сохранения!
"более простой код" "в одну строчку" !