ИзопропилТ.е. пишется нечто без выяснения потребностей ?Расскажите мне пожалуйста про кастомеров SQL Server, и про их потребности.

Arm79Тогда зачем описывать сферического коня в вакууме? Универсальной таблетки нет. И пытаться делать супер-пупер архитектуру на все случаи жизни бессмысленно. Тот же пример с СУБД - если они так хороши и универсальны, почему появляются embedded СУБД, key-value хранилища или in-memory database системы?Никто и пытается сделать универсальную таблетку. Можно пытаться покрыть все возможные сценарии, и никогда это не сделать, так как это по определению невозможно. Можно вообще ничего не делать, и сказать кастомеру: "У меня ничего нет, но как у вас появятся какие-то требования, приходите, сделаем под вас". Это два экстремума. Истина находится посередине. Я не делаю универсальную таблетку, я покрываю наиболее вероятные сценарии.

Arm79Если вы так озабочены конкурентными преимуществами - дарю идею: в вашу прикладную неконкретную систему-конструктор заложите еще выборочные защиту целостности (ЭЦП), конфиденциальность (шифрование), сжатие (архивирование), защиту от DDOS, MIM, не забудьте интеграцию с каким-нибудь аутентификационным центром наподобие Tivoli Access Manager.Все это нахер никому не нужно. Если все же потребуется, прикрутить все это - дело пяти минут. А написать нормальный алгоритм и затюнить его до зубов - задача совершенно иной трудоемкости.

Arm79И у меня еще вопрос. Если .Net так плох, а вам нужны любые преимущества над конкурентами, то почему вы не сделаете вашу систему на Java, который обгоняет с++ по скорости исполнения кода, и .Net - по скорости разработки?Писал уже - продукт кросс-платформенный, .Net - одна из платформ.

netivanТо что он не рубит в Нет это давно понятно.Осмелюсь заявить (особенно принимая во внимание темы вашего раздела в духе "Надо ли писать юнит-тесты?" и "Зачем знать потроха .Net?"), что я по своим знаниям core .Net дам прикурить 95% мемберов этого форума.

Изопропилнапример - http://www.microsoft.com/sqlserver/ru/ru/sql-2012-editions.aspx
На курсы маркетинга сходиЗамечательно, вы мне вместо ответа дали рекламный буклетик. Ну пусть хоть так. Теперь следующий вопрос: отталкиваясь от этих требований осмелились бы вы, например, реализовать движок SQL Server так, что бы он все хранил в виде XML? Или полностью забить на кэширование результатов запросов? Или не запариваться с какими-то непонятными merge и hash join'ами, а просто в оптимайзере херачить по индексам сверху вних, вне зависимости от условий? Не, вообще индексы выпилть? И оптимайзер до кучи? Сделали бы вы так, зная, что у конкурентов все это есть, и что благодаря этому конкуренты от вас мокрого места не оставят?
авторНу а чо, ведь есть же кастомеры, которым не нужно "быстро"? Да и диски нынче дешевые, можно и в XML все хранить. А индексы - так это вообще premature optimization! Сначала докажите, от бинарного индекс дает выигрыш в скорости, который нужен кастомеру!
Как вам перспективка, м?

hVosttА мы ведь так и не услышали от вас ни одного слова конкретики. Одни рассуждения о неведомых скоростях и злых конкурентов, которые горячо дышат в спину. Пока что в вашем лице наблюдается конкурент Донцовой, но не разработчиков. По крайне мере дотнетчикам уж точно переживать не стоит. Будет уже что-нибудь по существу или нет?А я что, помощи прошу что ли, чтобы вдаваться в конкретику? Помощь нужна вам - вы же не понимаете в чем разница меду разработкой типичной корпоративной системы с четкими требованиями, и разработкой коробочного продукта, а не я.

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

Вы, коллеги дотнетовцы, должны понять, что услышать где-то фразу "premature optimization is pure evil" - это не значит понять ее суть. Вы, например, почти поголовно не понимаете ее. Ведь надо не только не избегать premature optimization, но и уметь отличить, где оптимизация оправдана, а где действительно "premature". А эта грань очень сильно варьирует от контекста задачи. В типичной корпоративке, где пользователи лениво плыкают на кнопки, и ни о каком перфомансе речи не идет в принципе, эта грань одна. В коробочном решении, в котором о требованиях пользователя изначально известно только то, что он будет гонять какие-то данные, эта грань совершенно иная.

Поэтому не надо мне рассказывать про XML. В ваших решениях он работает, в моем нет. Ведь если я буду заворачивать свои сообщения в SOAP, то для случая, когда пользователь гоняет туда-сюда тексты книг, накладные расходу на конверт после амортизации составят доли процента, а если он будет гонять туда-сюда, скажем, отдельные интеджеры (4 байта), то накладные расходу будут 2000%. А в типичном случае, когда он гоняет некий объект с полями разных типов, они будут, нуу, процентов 200-300. Все это не катит. Мне нужно процентов 5, а лучше и еще меньше.
И не надо мне рассказывать, что "сеть сводит все ваши потуги на нет". Ну так пойдите расскажите об этом вашему любимому вендору. Пускай закрывает команду оптимизатора SQL Server - ведь все равно же IO есть (диск/сеть), значит вся их работа бесполезна. Ведь так? Конечно нет. Во-первых, IO можно уменьшать (например, уменьшая объем прокачиваемых данных, переходя от того же XML к бинарной форме). Во-вторых, с IO можно работать по-разному. У меня, например, нет ни одного блокирующего сетевого вызова, ибо селекторы. В-третьих, IO бывает разное. Бывает HDD, а бывает SSD. Бывает сеть 10Мбит, а бывает сеть 10Гбит, и я должен уметь нормально загрузить любое оборудование.
И т.д. и т.п..

В общем, просвещайтесь и развивайтесь.

hVostt ну так где это чёртов контекст задачи? если его нет, то нахрена тратить калории, бессмысленно нажимая кнопки? пока не будет контекста, эту свою лапшу про «прематуре», отведайте пожалуйста сами в ближайшей подворотне за углом. скармливать это гадость форумчанам не нужно.Контекст уже дан - быстрый кроссплатформенный сериализатор общего назначения.

Алексей К"Быстрый" не бывает "общего назначения".А если два "общего назначения" поставить рядом, то можно ли сказать, какой из них "быстрый", а какой "медленный"?