В каждом конкретном случае ответ свой — слишком мало информации.
Задаем себе вопрос — какие данные мне нужно будет читать/изменять атомарно? Ну и вот опираясь на это решаем, все хранить в документе, либо выносить полезную нагрузку в отдельную коллекцию.
MongoDB не любит сортировать более чем 1000 записей без индекса, так что для больших категорий сортировку по произвольным параметрам мы запретили. Но для фильтрации секрет я раскрою: Категория с 2445 товарами
Самое интересное было бы, как именно удалось построить «эффективную технологию построения логистики»
Это, как мне кажется, и есть суть успеха этого сервиса.
c текущим map/reduce еще ведь/ проблема что одновременно выполняется только 1 map reduce, а если новые функции не используют javascript то такого ограничения там не будет.
Точно — никак.
Заказчик крайне редко может вам рассказать полностью какой именно проект ему нужен.
Так зачем же строить иллюзии и тратить на это деньги? Примерный ориентир (1-2 месяц, 3-6, 6-9), если задача вам по плечу, можно назвать практически сразу, а вот в процессе работы все будет меняться.
Это не покупка мерседес, где все просчитано и стоимость каждой опции строго определена заранее. Но там кстати список опций будет предопределен и что-то добавить в него будет затруднительно.
Хочется сказать словами известной рекламы — «Вы еще делаете эстимейты? Тогда мы идем к вам!»
1. Заказчик хочет знать точные цифры по стоимости и срокам проекта до подписания договора
перевожу — а) заказчику придется переплатить 1000 часов для того чтобы иметь ложную уверенность, что он знает, во сколько обойдется его проект. На практике же:
б) Есть серьезный шанс, что получив такую оценку, заказчик откажется от проекта. Тогда эти десятки а то и сотни часов на оценку проекта будут потрачены впустую
в) если заказчик не откажется, то каков собственно смысл тратить время на оценку проекта? Лучше стартонуть на пару недель раньше.
г) в начале проекта будет казаться, что времени еще много, и все будут пинать. В конце проекта окажется, что хотя формально все задачи на 99% выполнены, последние проценты будут занимать не часы а недели. Особенно ухудшает ситуацию, если на повестке дня есть требования к производительности.
2. Соотношение сбора требований к программированию заложено 1 к 25. Это очень подозрительно много.
Либо вы используете устаревшие технологии, либо вы вообще не умеете работать/работаете командой без опыта совместной работы. Возможно, в каждом проекте кардинально меняется предметная область и технологии.
ну а вообще тут, конечно, куча книг написана на эту тему… Люди, забудьте о оценках проектов в часах — выиграют ВСЕ.
Оцените фичи по сложности (1-2-3), расставьте вместе с клиентом в порядке важности и последовательности, давайте ему попробовать результат каждые две недели. Через два месяца окажется, что то что казалось важным, можно сделать через год. А функция, о которой даже не думали, и определит успех проекта.
О, я нашел пример редактирования сложного объекта — Instructor/Edit, только почему-то там красота автоматического биндинга параметров в объект куда-то исчезает — просто разгребается FormCollection и все делается вручную :(
В какой-то мере оно полезно, и за перевод нужно однозначно сказать спасибо XaosCPS, но вот по содержанию…
Сколько еще микрософт будет держать всех за чайников? Ни одного примера редактирования сложного объекта здесь нет — только одна сущность за раз. Теже enrollment заполняются только при инициализации базы тчк
Учат молодое поколение писать неэффективный код, который генерирует N запросов к базе данных:
foreach (Enrollment enrollment in selectedCourse.Enrollments)
{
db.Entry(enrollment).Reference(x => x.Student).Load();
}
Зато да, красиво. А не дай бог студент в свою очередь вычитает какой-то еще список (в реальном проекте так и будет) и все, проект безбожно тормозит…
Я не использовал backbone, так что аргументировано ответить не могу. Могу посоветовать посмотреть примеры и сравнить код, который пишется на knockout и backbone и для себя решить, что понятнее и больше соответствует складу ума.
если кому мало мощности JS/Jquery рекомендую www.knockoutjs.com. Я с сентября с ним работаю, мне очень понравилось и я использую и буду использовать это в реальных проектах.
Плюсы:
— принципиально лучше user experience
— более структурированный js код в результате, который легче поддерживать
— переход общения клиент сервер на обмен данными(json) а не полями
К сожалению, в изучении не самая простая штука. Но если в что-то упретесь — всегда есть форум.
PS: МОжет написать статью о нем на хаббре? Хотя в принципе есть замечательное вводное видео…
Наверно те кто в теме действительно смогут настроить все сами.
А для новичка в memcache вроде меня заплатить лишний цент но сэкономить время на освоении развертывания и объединения этих нод в кластер (надеююсь, амазон это включил) наверно не было бы проблемой
Задаем себе вопрос — какие данные мне нужно будет читать/изменять атомарно? Ну и вот опираясь на это решаем, все хранить в документе, либо выносить полезную нагрузку в отдельную коллекцию.
Категория с 2445 товарами
Это, как мне кажется, и есть суть успеха этого сервиса.
И даже посещение домашней страницы ничего не объясняет. Это фишка?
Также еще можно ограниченно рекомендовать mongodb — mongodb — C# — knockoutjs очень хорошо сочетаются.
Заказчик крайне редко может вам рассказать полностью какой именно проект ему нужен.
Так зачем же строить иллюзии и тратить на это деньги? Примерный ориентир (1-2 месяц, 3-6, 6-9), если задача вам по плечу, можно назвать практически сразу, а вот в процессе работы все будет меняться.
Это не покупка мерседес, где все просчитано и стоимость каждой опции строго определена заранее. Но там кстати список опций будет предопределен и что-то добавить в него будет затруднительно.
1. Заказчик хочет знать точные цифры по стоимости и срокам проекта до подписания договора
перевожу — а) заказчику придется переплатить 1000 часов для того чтобы иметь ложную уверенность, что он знает, во сколько обойдется его проект. На практике же:
б) Есть серьезный шанс, что получив такую оценку, заказчик откажется от проекта. Тогда эти десятки а то и сотни часов на оценку проекта будут потрачены впустую
в) если заказчик не откажется, то каков собственно смысл тратить время на оценку проекта? Лучше стартонуть на пару недель раньше.
г) в начале проекта будет казаться, что времени еще много, и все будут пинать. В конце проекта окажется, что хотя формально все задачи на 99% выполнены, последние проценты будут занимать не часы а недели. Особенно ухудшает ситуацию, если на повестке дня есть требования к производительности.
2. Соотношение сбора требований к программированию заложено 1 к 25. Это очень подозрительно много.
Либо вы используете устаревшие технологии, либо вы вообще не умеете работать/работаете командой без опыта совместной работы. Возможно, в каждом проекте кардинально меняется предметная область и технологии.
ну а вообще тут, конечно, куча книг написана на эту тему… Люди, забудьте о оценках проектов в часах — выиграют ВСЕ.
Оцените фичи по сложности (1-2-3), расставьте вместе с клиентом в порядке важности и последовательности, давайте ему попробовать результат каждые две недели. Через два месяца окажется, что то что казалось важным, можно сделать через год. А функция, о которой даже не думали, и определит успех проекта.
Сколько еще микрософт будет держать всех за чайников? Ни одного примера редактирования сложного объекта здесь нет — только одна сущность за раз. Теже enrollment заполняются только при инициализации базы тчк
Учат молодое поколение писать неэффективный код, который генерирует N запросов к базе данных:
foreach (Enrollment enrollment in selectedCourse.Enrollments)
{
db.Entry(enrollment).Reference(x => x.Student).Load();
}
Зато да, красиво. А не дай бог студент в свою очередь вычитает какой-то еще список (в реальном проекте так и будет) и все, проект безбожно тормозит…
Вот похожие примеры:
http://documentcloud.github.com/backbone/examples/todos/index.html
js код к нему — http://documentcloud.github.com/backbone/examples/todos/todos.js
и knockoutjs:
knockoutjs.com/examples/betterList.html
«Чукча — не читатель, Чукча — писатель.»
Плюсы:
— принципиально лучше user experience
— более структурированный js код в результате, который легче поддерживать
— переход общения клиент сервер на обмен данными(json) а не полями
К сожалению, в изучении не самая простая штука. Но если в что-то упретесь — всегда есть форум.
PS: МОжет написать статью о нем на хаббре? Хотя в принципе есть замечательное вводное видео…
А почему бы не сделать проще — запустить НОВЫЙ инстанс и подменить ему sda1?
А для новичка в memcache вроде меня заплатить лишний цент но сэкономить время на освоении развертывания и объединения этих нод в кластер (надеююсь, амазон это включил) наверно не было бы проблемой
Если нужный человек доступен на landline то у него и интернет есть. Landline пригодится разве что звонить в какой-то банк и т.п.