tulyachkaКакой язык программирования подойдет для быстрого и качественного старта проекта типа 1c бухгалтерии. (множественные формы, рачеты, связи и зависимости)
C#

tulyachkaТакже интересует фронт-енд среда в частности библиотеки js(backbone, underscore), css(less, sass), html.
слышал что backbone неплохо работает с формаими, но не уверен что лучше использовать для такого проекта.
ASP.NET MVC + jQuery возьми, за глаза хватит.

P.S. И не забивай себе голову всякими бэкбонами, knockout и ангулярисами. Это тебе не нужно, поверь. Всё, что нужно, я перечислил выше. СУБД выбери любую по вкусу, но я бы взял MS SQL.

tulyachkaно я думаю что на них нельзя быстро нафигачить, что то быстро работающее за пару месяцев
"Быстро нафигачить" что-то более или менее серьезное ни на одном языке (платформе) нельзя. Если нужно "быстро нафигачить" - найми себе пяток студентов-нищебродов, они тебе за еду быстренько нафигачат. Только результат будет плачевный.

tulyachkaХотя возможно это зависит только от команды разработчиков...
Именно. И язык (платформа) роли никакой не играет (ну или почти не играет).

ShSergeОтдавайте данные в XML (SELECT ... RROM ... XML RAW) прямо с сервера
Серж опять жжёт... :)

МСУShSergeОтдавайте данные в XML (SELECT ... RROM ... XML RAW) прямо с сервера
Серж опять жжёт... :)
Серж, забудь об этом. Это плохо, очень плохо. Во-первых, данные должны приходить на сервер приложений в их натифном формате без каких-то сиквельных преобразований. Во-вторых, все преобразования (сериализация данных в XML, в JSON и т.д.) должно производиться силами application layer, ни в коем случае не силами БД. В-третьих, сам подход - жесть. Почему не общаться с БД, приложением, хендлерами, SOA и т.д. типизированно ?
P.S. Тема флудоносна, сразу скажу :)

ShSergeМСУ...данные должны приходить на сервер приложений в их натифном формате...
Ахренеть! И ты это умеешь?
ПС. Это - невозможно, деточка. (Ц).
Не передёргивай, ты понял о чем я говорю.

ShSergeМСУ, А SOAP - не XML что-ли?
Во-первых, SOA и SOAP - разные вещи. Если говорить о SOAP, я как-раз и писал о типизированном подходе (кодогенерация классов), а не ручных ковыряниях в XML.

AntonariyНе о бинарных TCP-пакетах же речь.
1. IDbCommand => SQL => DataSet / DataTable
2. ORM => SQL => IEnumerable<T>

ShSergeКстати, пхп, в отличие от сишарпа, специально для вэба делался.
Весьма некорректное сравнение.

AntonariyЭти слова что-то говорят о программных объектах и ничего о "нативном формате", вокруг которого они навернуты. Все равно не понятно, о чем речь.
Для тех, кто заперся в танке и не желает от туда выбираться. Речь о том, что из БД нужно выбирать данные без какой-либо трансформации. Трансформацию производить средствами application layer.

P.S. "Нативно выбрать" - это чистой воды аллегория. Другими словами, как вижу так и отдаю. Если требуются еще уточнения по этому поводу или захочешь опять понасиловать мой моск, убей себя об стену.

AntonariyДля начала, откуда ты знаешь, что никакой трансформации не происходит неявно при получении данных application layer'ом?
А мне это и не нужно знать, уже достаточно то, что он делает SQL FOR XML выборки. Более того, рекомендует это зло всем куда ни попадя.

AntonariyЕму же из бинарного потока нужно слепить объекты, для этого его нужно распарсить.
Не пиши чушь, какой еще "бинарный поток". Он делает выборку из обычных таблиц сразу в виде XML.

AntonariyА потом, for xml наверное не пяткой писали, и сделали узкоспециализированную процедуру, заточенную на максимальную производительность при формировании xml-текста из данных бд.
Лом тоже не зря придумали. Но использовать его в качестве отвертки - занятие неблагодарное.

AntonariyНикакой универсальный парсер application layer'а не сравнится по скорости выхлопа с узко заточенным.
Я бы не торопился с такими безапеляционными выводами - это раз. Выхлоп из базы должен быть в виде рекордсета без какого-либо форматирования, условной логики и прочего бреда. Логикой должен заниматься application layer и только он. Тогда отмасштабировать решения будет в разы проще, про переносимость БД - вообще как два пальца.

AntonariyЧто же получается, если нам нужно отдать xml клиенту? Как минимум две трансформации. Одна из бинарного стрима, отдаваемого сервером, в объекты типа DataSet/IEnumerable, вторая из объектов в стрим, содержащий xml-текст. +1, если не в стрим, а в XmlDocument.
Да, так и только так. Более того, одному клиенту нужна определенная xsd схема, другому - другая, третьему - третья. Писать этот ужос на SQL - проще убить себя об стену. Нормальные люди (подчеркиваю, нормальные люди) пишут .NET трансформер, богатый по функциональности и быстрый по исполнению.

AntonariyА если посмотреть на for xml, то получается, что транформацию в xml нам уже сделал сервер максимально эффективным способом, а если от xml больше ничего не надо, можно сделать ADODB.Stream -> Response.Stream без переливания из пустого в порожнее объекта в объект.
Написал выше. Более того, сейчас у нас сиквел, завтра оракл, последавтра попросят mysql. Засада? У меня нет, ибо вся логика в application layer.

AntonariyНо все это общие соображения для сферических задач.
Учи матчасть.

Antonariy,

60 миллисекунд на всё (выборка из БД, сериализация) - 1000 экземпляров [Sales].[Customer], результат 181 Кб (в аттаче), простая рабочая машина (не сервер).

Маленькая скорость?

Entity Framework

ShSergeМСУ...Учи матчасть.
У меня FOR XML на нескольких десятках миллионов данных работает меньше секунды.
Здесь смеяться или плакать?
В эти сказки даже дед мороз не поверит, получишь out of memory exception. Иди расскажи это бабушкам во дворе, и то засмеют.

ShSergeМСУ, Это твоё любимое ОРМ сделает. А у меня - всё типтоп.
Я ж говорю, иди деду морозу расскажи сказки, как ты сериализуешь в строку несколько десятков миллионов строк.

Тут чувак вешается от 220 тыщ, и все ему пальцем у виска крутят...

http://stackoverflow.com/questions/5899719/sql-query-for-xml-runs-fine-in-2000-slow-in-2008-r2 The table itself contains 220,500 rows but the query rows returned is showing 129,810 before query stops. Is this simply a matter of not having enough memory available to the system? This box has 48 GB (Win 2008 R2 EE x64), instance capped to 18GB because its shared dev environment.

а ты у нас такой весёлый, десятки миллионов строк в XML пихаешь, и всё это у тебя работает меньше секунды. Серж, ты не болен случаем?

handmadeFromRuShSergeА как это по-русски будет?
нечего было сказать?
п.с. вы имхо не вкурсе "как это работает" по ваших большинству постов
Я порой диву даюсь от постов Сержа...

ShSergeМСУ, Я очень осторожно подвожу тебя к мысли, что таки стоит чего-то делать на сервере.
Если это "что-то" реально оправдано, но я не против. Например, ORM-ы не умеют с деревьями рекурсионно через CTE работать. Да, идем в обход транслятора и пишем что-то такое . Или пишем хп, если очень припечет и оно того стоит. Но эти обходные пути - мизер, по сравнению с реальными потребностями.

ShSergeНесколько десятков миллионов у меня группируются до нескольких миллионов (суммируются).
1. Как-то ты аккуратно начал включать заднюю. У тебя может и 10 миллиардов сгруппироваться в одну строку и ты будешь всем писать, что "У меня FOR XML на нескольких десятках миллиардах данных работает меньше секунды"? Ну не бред ли?
2. Во вторых, даже если ты схлопнешь в несколько миллионов и накроешь их FOR XML, у тебя всё-равно не получится быстро это сделат
3. В третьих, сериализовать миллионы строк - попахивает кретинизмом. Не находишь?

ShSergeА там - дело техники. Несколько миллионов прекрасно себе сериализуются в ХМЛ. Но на SQL-сервере , а не на сишарпе, или ОРМе.
Да что ты говоришь? Расскажи, за какое у тебя время "несколько миллионов прекрасно себе сериализуются в ХМЛ"?

ShSergeЩас не могу послать тебе тестовый запрос, но как-нибудь сам попробуешь.
Давай!

ShSergeПардон, не десятки миллионов а сотни. :)
Так, начинали с десятков миллионов. Потом, оказывается, в сторонке отплясывала группировка и речь была о нескольких миллионах. Теперь уже "сотни". Только непонятно чего, миллионов или тысяч?

P.S. Серж, ты даже облажался на такой элементарной теме, как FOR XML... Даже студент знает, что это нереально тормозная хрень, которая еще более менее приемлема на небольшом кол-ве данных (сотни строк, ну тысячи максимум). И то, если речь идет о небольших по размеру row.

Алексей К Тут похожая тема. Сервера приложений можно без напряга горизонтально масштабировать. Поэтому всякие развороты данных/преобразование в XML/шифрование/сжатие и т. п. нужно по возможности выносить из БД. Масштабирование сервера БД (кластеризации, репликации и т. п.) - занятие не для слабонервных.
Вот, сразу чувствуется подход профессионала. Старик Алексей никогда не лажает! :) (ну или почти никогда )

Алексей КhandmadeFromRu- код на sql, в общем случае, выпадает из системы контроля версийСкрипты на создание хранимых процедур и т. п. прекрасно хранятся в версионнике.
SQL Server Database Project наше всё.

Алексей КМСУну или почти никогда Никогда!

ShSergeМСУ, Да, я действительно, причём через хттп (хендлером в формате ХМЛ) импортирую табличку с миллионами записей. Ну и что? У меня - работает.
Я тебе десятый раз говорю, нереально за приемлемое время прогнать через FOR XML такой набор. Я ж тебе даже пример привел, где чувак 220 тыщ строк 18 минут конвертил. Значит, не до конца ты знаешь свою систему, что я могу сказать. Учи её, читай код. Ты пишешь нереальные вещи, не понимаешь этого?

ShSergeЕсли у кого-то не работает, то что здесь сказать?
Хороший аргумент, зачёт :)

ShSerge1. Никогда не писать SELECT *, вопервых. :)
2. Привести базу в порядок (ну, там индексы и т.п.).
3. Забить на ОРМы.
Успехов!
И тогда будут миллионы сериализоваться меньше секунды? Этопять