а потом джойнить массивы? или просто хранить каждую коллекцию в своем массиве. Иногда требуется более трех джоинов за раз, в данном случае все преврятится в кучу кода. Да и после каждого запроса собирать уникальные ID тоже знаете ли.
Пока джоинов не будет — работать можно только с простыми данными.
отлично на странице блога будут показываться комментарии всех пользователей, скажем их 100. к каждому комментарию нужно показывать информацию о пользователе — это что, нужно по каждой записи делать запрос к коллекции Users?
простите я не понял про джоины. Можно на примере объяснить?
вот к примеру есть пользователи и есть коментарии, которые пользователи оставляют. Нужно вывести все комментарии пользователя Х, а так основную информацию о пользователе. Можете мне показать какие колекции я должен создать?
вообще непонятно как работает поиск, что там с индексами, с GROUP BY и самое главное как там с JOIN. Я так понимаю, что про типы данных не имеет смысла спрашивать. И еще непонятно какое количество записей может быть в одной колекции.
моя семья требует больше времени после работы чем 2 часа. Либо автор скинул всю семью на жену и стал обычным задротом, который всю жизнь проведет у компьютера, либо автор чего-то недоговаривает. Как можно придя с работы, заняться своим стартапом, если дома детишки, которые тебя не видели весь день и жена. А как же друзья и родственники, которые требует немало внимания. И это хорошо если дачи нету. Да и по дому всегда много работы.
А вот скажите мне пожалуйста, что лучше Планшетник взять или нет бук?
Нужно мыло, интернет, офис. Ну и естественно мобильность. Вот раньше хотел себе нетбук, а теперь смьорю вроде и планшетника хватит.
Ну можно мерять проект — но не программиста, дайте ему спокойно работать и грамотно ставьте задачи и мерять Вам его не придется. В проекте можно контролировать время и и сроки. Но нельзя мерять людей.
Вы говорите кодировать, простите, но чтобы кодировать много ума ненадо. Есть кодер есть девелопер, или разработчик, как Вам будет угодно. Да не все люди гении. Кто-то пишет код дольше, укого-то процесс разработки занимает больше времени (я имею ввиду именно процесс проектирования системы), но Вы этого никак не замеряете, потому как еще вмешивается психология. Да и вообще я же и предлагаю, давайте определимся что значит качество кода, а то мы будем мереть не то.
я должен отвечать на этот вопрос? по моему это более чем странно — руководить проектом о котором ничего не знаешь. Вопрос тут только — а руководите ли вы проектом?
Джоэл Спольский наоборот пишет, что у программиста ничего не надо мерить. Все эти измерения не объективны, а если проект 10 с конца, то это вина руководителя, проектом и людьми надо руководить, а не метрики мерить. На мой взгляд плохое качество кода лечится введением небольшого стандарта кодирования. Хотя если так задуматься, что это такое вообще качество кода? может начнем с определения, что бы все мы говорили об одном и том же.
Лично я думаю, что в интернет детей пускать надо, но естественно не везде. Можно, кстати, стартапчик сделать для детишек. Есть же детская железная дорога, почему не сделать детский интернет. Ну можно их всех через сервак пускать, который только нужные сайты показывать будет, так сказать проверенные и поисковик только по ним. Чтобы швали всякой детским глазам не показывать. Да и много детям надо?
А есть ли смысл тратить время, покрывая юнит тестами мелкий функционал, особенно отправку писем. Это достаточно просто проверяется и врядли сломается. А вот как раз бизнес логика, где полно связаных компонентов, вот тут и возникают проблемы, с тем, что после изменений система работает, но с ошибкой. Из моего опыта чаще всего появляются баги:
1) верстка — тут уж только визуально, заодно и тестирование функционала
2)SQl скрипты — из за ошибки в скрипте берутся либо не те данные, либо не в правильном порядке, либо сохраняются нетуда, ХЗ как такое проверить и протестировать
3) Логика — чаще всего в операторах IF и switch. тут как раз, как я понимаю, и помогут юнит тесты.
4) плохие входные данные — тут опять же помогут юнит тесты.
а где можно почитать побольше про юнит тесты? у меня возникла проблема с ними — на этапе разработки слишком много времени уходит на написание фикстур и т.д. Как правильно пользовать юнит тесты в условиях быстро меняющихся условий?
SELECT a.*, c.* FROM articles a INNER JOIN categories c ON a.category_id = c.id WHERE a.shared = 1
на
find_function = function(cond){
var categoriesHash = {};
var categoryIds = [];
db.categories.find(cond)
.forEach(function©{
categoriesHash[c._id.toString()] = c;
categoryIds.push(c._id);
});
var result = [];
db.articles.find({category_id: {"$in": categoryIds}}).forEach(function(a) {
a.category = categoriesHash[a.category_id.toString()];
result.push(a);
});
return result;
}
db.articles.eval(find_function);
db.articles.eval(find_function, {shared: 1});
немного не по мне. Дело вкуса конечно. ну и конечно я сомневаюсь, что тут будет высокая производительность.
Пока джоинов не будет — работать можно только с простыми данными.
вот к примеру есть пользователи и есть коментарии, которые пользователи оставляют. Нужно вывести все комментарии пользователя Х, а так основную информацию о пользователе. Можете мне показать какие колекции я должен создать?
Нужно мыло, интернет, офис. Ну и естественно мобильность. Вот раньше хотел себе нетбук, а теперь смьорю вроде и планшетника хватит.
1) верстка — тут уж только визуально, заодно и тестирование функционала
2)SQl скрипты — из за ошибки в скрипте берутся либо не те данные, либо не в правильном порядке, либо сохраняются нетуда, ХЗ как такое проверить и протестировать
3) Логика — чаще всего в операторах IF и switch. тут как раз, как я понимаю, и помогут юнит тесты.
4) плохие входные данные — тут опять же помогут юнит тесты.