Сообщение Re[8]: Какие фреймворки использовать для прототипа? от 08.05.2015 14:13
Изменено 08.05.2015 14:20 0BD11A0D
Здравствуйте, gandjustas, Вы писали:
BDA>>Давайте поговорим про яйца, мне не трудно. Тем более, все в рамках темы, вроде бы. Не оффтопик, не холивор. Дык вот, как там, в ШП 2013/15/17, стало уже можно проапдейтить список одной транзакцией? Не по примеру из учебников, типа одно и то же значение суем в 100% элементов (bulk update), а вот... пусть у вас будет заделан CRM. В списке хранятся операции с клиентами. Можно найти все операции для кастомеров (из отдельного списка), подпадающих под некоторое условие (город, где у них офис) и поднять им приоритет? И не итеративно в цикле через ОМ, а транзакционно?
G>Можно, джоины есть, массовые операции через process batch data http://apmblog.dynatrace.com/2009/01/20/sharepoint-using-batch-updates-to-speed-up-performance/
Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
То есть, по сути, эти чижики взяли 5% SQL, завернули его в модный тогда XML, и вот с этим предлагается работать.
Если CAML с тех пор стал поддерживать не 5% SQL, а хотя бы столько, сколько надо для выполнения указанной операции, или, может быть, сам CAML выкинули на помойку, заменив его еще каким-нибудь хренамлом, то с этого и надо начинать.
G>Но SharePoint рассчитан именно на работ с отдельными записями, даже в режиме редактирования таблицы массовые изменения по одному отправляются на сервер, поэтому такие вещи как ты пишешь там неудобны.
Во-первых, не неудобны, а НЕВОЗМОЖНЫ. Вот, цитирую картинку. Она одна круче всяких слов:
При переходе от поэлементной обработки к пакетной НА СТА ЗАПИСЯХ ОНИ СУМЕЛИ СОКРАТИТЬ ВРЕМЯ с 4.5 СЕКУНД ДО 2.7! Рекорд, млять, для книги Гиннесса. Теперь, я думаю, те, кто это читают, поймут, что не уложиться в 30 секунд таймаута там не просто, а очень просто. А потом цикл будет просто прерван в середине, привет, неконсистентность.
Во-вторых, именно это и делает ШП игрушкой. Зашибись: таблицы есть, а работать с табличными данными нельзя.
На самом-то деле, можно, конечно. Если есть компьютер и программа, все можно, если захотеть. Я тут дурачка включил, думал, послушаю, что умные люди скажут. Но не дождавшись ничего умного, рассказываю, как это делается на самом деле. Сначала вы берете всех этих ханжей, которые говорят, что в БД лазить можно только через CAML/OM, и посылаете в большую и черную жо. Затем пишете триггеры и хранимки на SQL CLR, которые умеют маппить имена списков, с которыми вы работаете, в допусловия для WHERE при UPDATE [AllUserData]. Потом начинается самое веселое: поскольку формулы у них считаются не в хранимках, а в памяти, на C++ (да, я пытался сделать reverse engineering), то их после UPDATE все надо выполнить вручную. То есть, написать парсер/калькулятор и менеджер триггеров, чтоб он на собственные обновления не реагировал.
И только с приемами типа такого можно достичь скорости, которой хватит для реального применения. У меня даже остался набор инструментов, который все это делает. Во всех остальных случаях можно просто взять бесплатную CMS'ку (для портала) или Access (для построчного редактирования) и не иметь себе и другим мозгА.
G>Для CRM я бы взял dynamics crm, но там нет версионности на каждое изменение.
Да, много чего можно взять, если задаться целью купить у Микрохвоста.
G>Но это мы опять о танцорах. А теперь давай к реальности.
Реальность я описал вам выше. Но вы ее проигнрорировали. Как там поднять приоритет, а?
>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице)
Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие.
>, и тебе нужно решить ту же проблему. Найти все операции кастомеров по определенному критерию и поднять приоритет. Не забываем, что на каждую операцию и у тебя появилась новая версия. А надо бы еще не время операции не заблокировать таблицу данных на запись (ибо очень сильно ударит по быстродействию системы). Можешь хотя бы примерно описать как это сделать "транзакционно"?
Это называется «хобот в жопу». Я сюда пришел с вопросом, как это сделать — один вопрос был задан в этом форуме, второй вопрос в соседнем (про БД). Научив попутно шаропоинтщика тонкостям работы с шаропоинтом, через три итерации я встречаюсь со своим же собственным вопросом. «Вечный кайф!»
G>Ты ушел от ответа на вопрос. Свой аналог ты сколько пилить собрался? Чтобы он и массовые операции поддерживал, и таблицы в базе не трогал (как 1С или dynamics crm), да еще и работал быстро с любыми серьезными объемами данных.
G>Ты можешь 100500 раз ругать системы типа шарика, или dynamics, или 1С, или что еще там тебе может не нравится. Но они позволят этот самый прототип, с которого началась тема, запилить от силы за пару часов.
Буквальный ответ: чем быстрее, тем лучше. Просто вы не понимаете, что требуется. Как бы мне объяснить, чем фреймворк отличается от готового продукта, купленного за большие деньги...
BDA>>Давайте поговорим про яйца, мне не трудно. Тем более, все в рамках темы, вроде бы. Не оффтопик, не холивор. Дык вот, как там, в ШП 2013/15/17, стало уже можно проапдейтить список одной транзакцией? Не по примеру из учебников, типа одно и то же значение суем в 100% элементов (bulk update), а вот... пусть у вас будет заделан CRM. В списке хранятся операции с клиентами. Можно найти все операции для кастомеров (из отдельного списка), подпадающих под некоторое условие (город, где у них офис) и поднять им приоритет? И не итеративно в цикле через ОМ, а транзакционно?
G>Можно, джоины есть, массовые операции через process batch data http://apmblog.dynatrace.com/2009/01/20/sharepoint-using-batch-updates-to-speed-up-performance/
Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
UPDATE Operations
SET Priority="High"
WHERE Client IN (SELECT Id FROM Clients WHERE City=:city);То есть, по сути, эти чижики взяли 5% SQL, завернули его в модный тогда XML, и вот с этим предлагается работать.
Если CAML с тех пор стал поддерживать не 5% SQL, а хотя бы столько, сколько надо для выполнения указанной операции, или, может быть, сам CAML выкинули на помойку, заменив его еще каким-нибудь хренамлом, то с этого и надо начинать.
G>Но SharePoint рассчитан именно на работ с отдельными записями, даже в режиме редактирования таблицы массовые изменения по одному отправляются на сервер, поэтому такие вещи как ты пишешь там неудобны.
Во-первых, не неудобны, а НЕВОЗМОЖНЫ. Вот, цитирую картинку. Она одна круче всяких слов:
При переходе от поэлементной обработки к пакетной НА СТА ЗАПИСЯХ ОНИ СУМЕЛИ СОКРАТИТЬ ВРЕМЯ с 4.5 СЕКУНД ДО 2.7! Рекорд, млять, для книги Гиннесса. Теперь, я думаю, те, кто это читают, поймут, что не уложиться в 30 секунд таймаута там не просто, а очень просто. А потом цикл будет просто прерван в середине, привет, неконсистентность.
Во-вторых, именно это и делает ШП игрушкой. Зашибись: таблицы есть, а работать с табличными данными нельзя.
На самом-то деле, можно, конечно. Если есть компьютер и программа, все можно, если захотеть. Я тут дурачка включил, думал, послушаю, что умные люди скажут. Но не дождавшись ничего умного, рассказываю, как это делается на самом деле. Сначала вы берете всех этих ханжей, которые говорят, что в БД лазить можно только через CAML/OM, и посылаете в большую и черную жо. Затем пишете триггеры и хранимки на SQL CLR, которые умеют маппить имена списков, с которыми вы работаете, в допусловия для WHERE при UPDATE [AllUserData]. Потом начинается самое веселое: поскольку формулы у них считаются не в хранимках, а в памяти, на C++ (да, я пытался сделать reverse engineering), то их после UPDATE все надо выполнить вручную. То есть, написать парсер/калькулятор и менеджер триггеров, чтоб он на собственные обновления не реагировал.
И только с приемами типа такого можно достичь скорости, которой хватит для реального применения. У меня даже остался набор инструментов, который все это делает. Во всех остальных случаях можно просто взять бесплатную CMS'ку (для портала) или Access (для построчного редактирования) и не иметь себе и другим мозгА.
G>Для CRM я бы взял dynamics crm, но там нет версионности на каждое изменение.
Да, много чего можно взять, если задаться целью купить у Микрохвоста.
G>Но это мы опять о танцорах. А теперь давай к реальности.
Реальность я описал вам выше. Но вы ее проигнрорировали. Как там поднять приоритет, а?
>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице)
Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие.
>, и тебе нужно решить ту же проблему. Найти все операции кастомеров по определенному критерию и поднять приоритет. Не забываем, что на каждую операцию и у тебя появилась новая версия. А надо бы еще не время операции не заблокировать таблицу данных на запись (ибо очень сильно ударит по быстродействию системы). Можешь хотя бы примерно описать как это сделать "транзакционно"?
Это называется «хобот в жопу». Я сюда пришел с вопросом, как это сделать — один вопрос был задан в этом форуме, второй вопрос в соседнем (про БД). Научив попутно шаропоинтщика тонкостям работы с шаропоинтом, через три итерации я встречаюсь со своим же собственным вопросом. «Вечный кайф!»
G>Ты ушел от ответа на вопрос. Свой аналог ты сколько пилить собрался? Чтобы он и массовые операции поддерживал, и таблицы в базе не трогал (как 1С или dynamics crm), да еще и работал быстро с любыми серьезными объемами данных.
G>Ты можешь 100500 раз ругать системы типа шарика, или dynamics, или 1С, или что еще там тебе может не нравится. Но они позволят этот самый прототип, с которого началась тема, запилить от силы за пару часов.
Буквальный ответ: чем быстрее, тем лучше. Просто вы не понимаете, что требуется. Как бы мне объяснить, чем фреймворк отличается от готового продукта, купленного за большие деньги...
Re[8]: Какие фреймворки использовать для прототипа?
Здравствуйте, gandjustas, Вы писали:
BDA>>Давайте поговорим про яйца, мне не трудно. Тем более, все в рамках темы, вроде бы. Не оффтопик, не холивор. Дык вот, как там, в ШП 2013/15/17, стало уже можно проапдейтить список одной транзакцией? Не по примеру из учебников, типа одно и то же значение суем в 100% элементов (bulk update), а вот... пусть у вас будет заделан CRM. В списке хранятся операции с клиентами. Можно найти все операции для кастомеров (из отдельного списка), подпадающих под некоторое условие (город, где у них офис) и поднять им приоритет? И не итеративно в цикле через ОМ, а транзакционно?
G>Можно, джоины есть, массовые операции через process batch data http://apmblog.dynatrace.com/2009/01/20/sharepoint-using-batch-updates-to-speed-up-performance/
Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
То есть, по сути, эти чижики взяли 5% SQL, завернули его в модный тогда XML, и вот с этим предлагается работать.
Если CAML с тех пор стал поддерживать не 5% SQL, а хотя бы столько, сколько надо для выполнения указанной операции, или, может быть, сам CAML выкинули на помойку, заменив его еще каким-нибудь хренамлом, то с этого и надо начинать.
G>Но SharePoint рассчитан именно на работ с отдельными записями, даже в режиме редактирования таблицы массовые изменения по одному отправляются на сервер, поэтому такие вещи как ты пишешь там неудобны.
Во-первых, не неудобны, а НЕВОЗМОЖНЫ. Вот, цитирую картинку. Она одна круче всяких слов:
При переходе от поэлементной обработки к пакетной НА СТА ЗАПИСЯХ ОНИ СУМЕЛИ СОКРАТИТЬ ВРЕМЯ с 4.5 СЕКУНД ДО 2.7! Рекорд, млять, для книги Гиннесса. Теперь, я думаю, те, кто это читают, поймут, что не уложиться в 30 секунд таймаута там не просто, а очень просто. А потом цикл будет просто прерван в середине, привет, неконсистентность.
Во-вторых, именно это и делает ШП игрушкой. Зашибись: таблицы есть, а работать с табличными данными нельзя.
На самом-то деле, можно, конечно. Если есть компьютер и программа, все можно, если захотеть. Я тут дурачка включил, думал, послушаю, что умные люди скажут. Но не дождавшись ничего умного, рассказываю, как это делается на самом деле. Сначала вы берете всех этих ханжей, которые говорят, что в БД лазить можно только через CAML/OM, и посылаете в большую и черную жо. Затем пишете триггеры и хранимки на SQL CLR, которые умеют маппить имена списков, с которыми вы работаете, в допусловия для WHERE при UPDATE [AllUserData]. Потом начинается самое веселое: поскольку формулы у них считаются не в хранимках, а в памяти, на C++ (да, я пытался сделать reverse engineering), то их после UPDATE все надо посчитать вручную. То есть, написать самому парсер/калькулятор языка расчетов и менеджер триггеров, чтоб он на собственные обновления не реагировал.
И только с приемами типа такого можно достичь скорости, которой хватит для реального применения. У меня даже остался набор инструментов, который все это делает. Во всех остальных случаях можно просто взять бесплатную CMS'ку (для портала) или Access (для построчного редактирования) и не иметь себе и другим мозгА.
G>Для CRM я бы взял dynamics crm, но там нет версионности на каждое изменение.
Да, много чего можно взять, если задаться целью купить у Микрохвоста.
G>Но это мы опять о танцорах. А теперь давай к реальности.
Реальность я описал вам выше. Но вы ее проигнрорировали. Как там поднять приоритет, а?
>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице)
Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие.
>, и тебе нужно решить ту же проблему. Найти все операции кастомеров по определенному критерию и поднять приоритет. Не забываем, что на каждую операцию и у тебя появилась новая версия. А надо бы еще не время операции не заблокировать таблицу данных на запись (ибо очень сильно ударит по быстродействию системы). Можешь хотя бы примерно описать как это сделать "транзакционно"?
Это называется «хобот в жопу». Я сюда пришел с вопросом, как это сделать — один вопрос был задан в этом форуме, второй вопрос в соседнем (про БД). Научив попутно шаропоинтщика тонкостям работы с шаропоинтом, через три итерации я встречаюсь со своим же собственным вопросом. «Вечный кайф!»
G>Ты ушел от ответа на вопрос. Свой аналог ты сколько пилить собрался? Чтобы он и массовые операции поддерживал, и таблицы в базе не трогал (как 1С или dynamics crm), да еще и работал быстро с любыми серьезными объемами данных.
G>Ты можешь 100500 раз ругать системы типа шарика, или dynamics, или 1С, или что еще там тебе может не нравится. Но они позволят этот самый прототип, с которого началась тема, запилить от силы за пару часов.
Буквальный ответ: чем быстрее, тем лучше. Просто вы не понимаете, что требуется. Как бы мне объяснить, чем фреймворк отличается от готового продукта, купленного за большие деньги...
BDA>>Давайте поговорим про яйца, мне не трудно. Тем более, все в рамках темы, вроде бы. Не оффтопик, не холивор. Дык вот, как там, в ШП 2013/15/17, стало уже можно проапдейтить список одной транзакцией? Не по примеру из учебников, типа одно и то же значение суем в 100% элементов (bulk update), а вот... пусть у вас будет заделан CRM. В списке хранятся операции с клиентами. Можно найти все операции для кастомеров (из отдельного списка), подпадающих под некоторое условие (город, где у них офис) и поднять им приоритет? И не итеративно в цикле через ОМ, а транзакционно?
G>Можно, джоины есть, массовые операции через process batch data http://apmblog.dynatrace.com/2009/01/20/sharepoint-using-batch-updates-to-speed-up-performance/
Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
UPDATE Operations
SET Priority="High"
WHERE Client IN (SELECT Id FROM Clients WHERE City=:city);То есть, по сути, эти чижики взяли 5% SQL, завернули его в модный тогда XML, и вот с этим предлагается работать.
Если CAML с тех пор стал поддерживать не 5% SQL, а хотя бы столько, сколько надо для выполнения указанной операции, или, может быть, сам CAML выкинули на помойку, заменив его еще каким-нибудь хренамлом, то с этого и надо начинать.
G>Но SharePoint рассчитан именно на работ с отдельными записями, даже в режиме редактирования таблицы массовые изменения по одному отправляются на сервер, поэтому такие вещи как ты пишешь там неудобны.
Во-первых, не неудобны, а НЕВОЗМОЖНЫ. Вот, цитирую картинку. Она одна круче всяких слов:
При переходе от поэлементной обработки к пакетной НА СТА ЗАПИСЯХ ОНИ СУМЕЛИ СОКРАТИТЬ ВРЕМЯ с 4.5 СЕКУНД ДО 2.7! Рекорд, млять, для книги Гиннесса. Теперь, я думаю, те, кто это читают, поймут, что не уложиться в 30 секунд таймаута там не просто, а очень просто. А потом цикл будет просто прерван в середине, привет, неконсистентность.
Во-вторых, именно это и делает ШП игрушкой. Зашибись: таблицы есть, а работать с табличными данными нельзя.
На самом-то деле, можно, конечно. Если есть компьютер и программа, все можно, если захотеть. Я тут дурачка включил, думал, послушаю, что умные люди скажут. Но не дождавшись ничего умного, рассказываю, как это делается на самом деле. Сначала вы берете всех этих ханжей, которые говорят, что в БД лазить можно только через CAML/OM, и посылаете в большую и черную жо. Затем пишете триггеры и хранимки на SQL CLR, которые умеют маппить имена списков, с которыми вы работаете, в допусловия для WHERE при UPDATE [AllUserData]. Потом начинается самое веселое: поскольку формулы у них считаются не в хранимках, а в памяти, на C++ (да, я пытался сделать reverse engineering), то их после UPDATE все надо посчитать вручную. То есть, написать самому парсер/калькулятор языка расчетов и менеджер триггеров, чтоб он на собственные обновления не реагировал.
И только с приемами типа такого можно достичь скорости, которой хватит для реального применения. У меня даже остался набор инструментов, который все это делает. Во всех остальных случаях можно просто взять бесплатную CMS'ку (для портала) или Access (для построчного редактирования) и не иметь себе и другим мозгА.
G>Для CRM я бы взял dynamics crm, но там нет версионности на каждое изменение.
Да, много чего можно взять, если задаться целью купить у Микрохвоста.
G>Но это мы опять о танцорах. А теперь давай к реальности.
Реальность я описал вам выше. Но вы ее проигнрорировали. Как там поднять приоритет, а?
>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице)
Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие.
>, и тебе нужно решить ту же проблему. Найти все операции кастомеров по определенному критерию и поднять приоритет. Не забываем, что на каждую операцию и у тебя появилась новая версия. А надо бы еще не время операции не заблокировать таблицу данных на запись (ибо очень сильно ударит по быстродействию системы). Можешь хотя бы примерно описать как это сделать "транзакционно"?
Это называется «хобот в жопу». Я сюда пришел с вопросом, как это сделать — один вопрос был задан в этом форуме, второй вопрос в соседнем (про БД). Научив попутно шаропоинтщика тонкостям работы с шаропоинтом, через три итерации я встречаюсь со своим же собственным вопросом. «Вечный кайф!»
G>Ты ушел от ответа на вопрос. Свой аналог ты сколько пилить собрался? Чтобы он и массовые операции поддерживал, и таблицы в базе не трогал (как 1С или dynamics crm), да еще и работал быстро с любыми серьезными объемами данных.
G>Ты можешь 100500 раз ругать системы типа шарика, или dynamics, или 1С, или что еще там тебе может не нравится. Но они позволят этот самый прототип, с которого началась тема, запилить от силы за пару часов.
Буквальный ответ: чем быстрее, тем лучше. Просто вы не понимаете, что требуется. Как бы мне объяснить, чем фреймворк отличается от готового продукта, купленного за большие деньги...