@borodutcher

« Назад

Страница 3052 из 10003

Далее »

Vladislav

19.03.2017
22:21:32

надолго

никита сыч, опять наебал :C

Anastasia

19.03.2017
22:21:59

у меня вообще стрим не грузится

Vladislav

19.03.2017
22:22:57

у меня вообще стрим не грузится

он сказал что скоро тян вернется и стрим офф\\\

MaxCos

19.03.2017
22:26:11

у меня вообще стрим не грузится

это фишка у Никиты такая.

Google

Aler

19.03.2017
22:27:05

парни, а объясните пожалуйста за mongo

вот если у меня есть объект А содержащий в себе N-е количество объектов Б

при том, что объекты Б сами по себе ценности не несут и запрашиваться по отдельности не будут

для них надо создать отдельную таблицу или писать прямо в объект А?

в какой-нибудь список

Просто в SQL понятно как - создаешь foreigKey и OneToMany

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

Vladislav

19.03.2017
22:29:18

писать прямо в объект А? -» в какой-нибудь список это как? таблица же и есть список

Aler

19.03.2017
22:30:21

ты в реалиях SQL как и я, друг

в BSON можно массив записать в "ячейку"

и размер каждой "строки" базы не обязательно должен быть одной длинны в байтах

Eugene

19.03.2017
22:32:24

вот из-за этого всего и не могу в монгу начать и не тянет чот :)

Aler

19.03.2017
22:33:12

Ну я себе это объясняю примерно так: это не база данных, а просто объекты в памяти.

Google

Aler

19.03.2017
22:33:33

но так как они большие, то приходится использовать подгрузку с жесткого

Eugene

19.03.2017
22:33:35

просто json это у меня в голове)

Aler

19.03.2017
22:33:39

так как все в память не положешь

Михаил

19.03.2017
22:34:45

если нужно указать, что свойство это массив объектов то делают users: [{ type: Schema.ObjectId, ref: 'user', required: true, default: [], }], и создают отдельную модельку юзера

Aler

19.03.2017
22:35:08

ты уверен, что это правильно?

Я - нет. Я специально добавить вводную

что сами по себе данные мне запрашивать не придется

с юзерами другая история. Нужно иметь возможность запросить db.users.find и тд

Георгий

19.03.2017
22:36:26

https://iamtrask.github.io/2017/03/17/safe-ai/

#чистопочитать

Aler

19.03.2017
22:36:58

я прав оказывается

запросить большой объект лучше, чем 10 маленьких

надо максимально записывать в модель

так как populate дорого делать очень в монго

Vladislav

19.03.2017
22:38:00

а где оно дешево

Nikita

19.03.2017
22:38:06

че как стрим

Aler

19.03.2017
22:38:15

в SQL

в SQL лучше выносить данные, чем выделить под них 100500кб )

для того чтобы записать в поле массив и рядом его длинну

Eugene

19.03.2017
22:38:59

а почему не взять sql базу?:)

Google

Aler

19.03.2017
22:40:28

да, просто интересно. Монго надо в 2к17 понимать и знать

а вообще, я даже не для монго интересуюсь, а для кассандры

но сначала надо понять монго, чтобы в кассандру входить

Vladislav

19.03.2017
22:41:08

все стрим офф?

в SQL лучше выносить данные, чем выделить под них 100500кб )

всмысле выносить о_О куда?

Aler

19.03.2017
22:41:38

всмысле выносить о_О куда?

в отдельную таблицу

Anastasia

19.03.2017
22:41:51

А кстати Камиль оказывается уже давно достаточно копает vue js

Vladislav

19.03.2017
22:42:05

так у тебя модель и есть абстракция таблицы

Aler

19.03.2017
22:42:43

в монго нету таблиц

А кстати Камиль оказывается уже давно достаточно копает vue js

ну да, он все эксперименты же на нем делает

Nikita

19.03.2017
22:43:19

как сейчас стрим?

Anastasia

19.03.2017
22:44:59

как сейчас стрим?

не работает

Aler

19.03.2017
22:45:06

серьезно, @hi4C0CK, тебе тоже бы за монго для общего развития почитать :)

Nikita

19.03.2017
22:45:15

не работает

перезапускал :)

Vladislav

19.03.2017
22:46:39

да я читал, много думал, хуита почищще ОРМ, "для своих задач". Не вижу плюсов с точки зрения для продакшена, расскажешь?

Aler

19.03.2017
22:47:34

скалабилити и параллелизм

это отличная база, например, для GameData

когда тебе надо ивенты, решения игроков и тд вносить базу

малыми партиями из 100500 потоков сервера и одновременно по 100500 запросов делать туда сюда

SQL по дизайну должен быть синхронным. Есть конечно всякие шаманства, но они придуманы как костыли к синхронному дизайну SQL

Google

Admin

ERROR: S client not available

Nikita

19.03.2017
22:49:55

все!!!

поправил стрим!!!

Aler

19.03.2017
22:51:12

одновременная запись 100 строк в sql идет по двум сценариям: 1) Одна за одной 2) Создаются dummy 100 строк и запускается асинхронные треды изменяющие их

в монго\кассандре же ты просто 100 записей делаешь параллельно и ок

но минусы в том, что даже получение по id объекта нихрена не дешевое (по сравнению с SQL)

в общем, я сам не специалист, но преимущества есть и недостатки. Они не заменяют друг друга в больших проектах, а дополняют

Vladislav

19.03.2017
23:11:41

одновременная запись 100 строк в sql идет по двум сценариям: 1) Одна за одной 2) Создаются dummy 100 строк и запускается асинхронные треды изменяющие их

учитывая что ты никогда не обновляешь просто 100 строк а пихаешь вообще кучу всего,то асинхронные треды вполне нормусь. Вообщем еще почитал, масштабируемость, окда, но все остальное дикая вкусовщина. Вообщем, полностью согласен: "То есть, если нам нужно сделать что-то вроде JOIN, мы можем сходить выбрать данные, потом сходить выбрать данные по ссылкам и затем их обработать на стороне приложения. Для людей, которые знают язык SQL, это выглядит как-то убого и ненатурально. Но на самом деле для многих разработка application-серверов такое куда проще, чем разбираться с JOIN." ну и подытоживая - не вижу не единой причины использовать монго, если можно заюзать сикуль, но и другим запрещать, конечно не буду.

Mr_Babrums.bin