Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
G>>Плохому танцору... ну ты понял.
BDA>Давайте поговорим про яйца, мне не трудно. Тем более, все в рамках темы, вроде бы. Не оффтопик, не холивор. Дык вот, как там, в ШП 2013/15/17, стало уже можно проапдейтить список одной транзакцией? Не по примеру из учебников, типа одно и то же значение суем в 100% элементов (bulk update), а вот... пусть у вас будет заделан CRM. В списке хранятся операции с клиентами. Можно найти все операции для кастомеров (из отдельного списка), подпадающих под некоторое условие (город, где у них офис) и поднять им приоритет? И не итеративно в цикле через ОМ, а транзакционно?
Можно, джоины есть, массовые операции через process batch data http://apmblog.dynatrace.com/2009/01/20/sharepoint-using-batch-updates-to-speed-up-performance/
Но SharePoint рассчитан именно на работ с отдельными записями, даже в режиме редактирования таблицы массовые изменения по одному отправляются на сервер, поэтому такие вещи как ты пишешь там неудобны.
Для CRM я бы взял dynamics crm, но там нет версионности на каждое изменение.
Но это мы опять о танцорах. А теперь давай к реальности. Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице), и тебе нужно решить ту же проблему. Найти все операции кастомеров по определенному критерию и поднять приоритет. Не забываем, что на каждую операцию и у тебя появилась новая версия. А надо бы еще не время операции не заблокировать таблицу данных на запись (ибо очень сильно ударит по быстродействию системы). Можешь хотя бы примерно описать как это сделать "транзакционно"?
BDA>>>Короче, я шарик раньше сам продавал кому хочешь, мне его продавать не надо. Я скорее на брейнфаке буду программировать СУБД под свою задачу, чем соглашусь еще раз коснуться этого отстоя. G>>Так тебе всетаки шашечки, а ехать и не нужно? Или ты думаешь, что запилив свою метамодель на СУБД с версионностью каждой строки у тебя прямо офигенский результат получится и язык запросов не жуже SQL? И сколько ты собрался это делать? Год? Два?
BDA>Зачем мне свой язык запросов? Я что, Майкрософт, с ее поиском фатальных недостатков? Если бы ШП давал SQL-интерфейс к [AllUserData], включая документацию, я бы, МОЖЕТ БЫТЬ, закрыл глаза на его общую упячность. А совсем без программирования у них тоже не получится — возьмем, например, такую ма-а-а-аленькую проблемку, как отказ считать результат агрегирующих функций (то, что во вьюхах идет как Total или типа того, не помню) гражданами первого класса, то есть элементами списков. Все-таки, dogfooding'а у них не было, это говорит каждый, кто пробовал запилить на шаре хотя бы элементарный багтрекер.
Ты ушел от ответа на вопрос. Свой аналог ты сколько пилить собрался? Чтобы он и массовые операции поддерживал, и таблицы в базе не трогал (как 1С или dynamics crm), да еще и работал быстро с любыми серьезными объемами данных.
Ты можешь 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> вы такое сложное условие не нарисуете:
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С, или что еще там тебе может не нравится. Но они позволят этот самый прототип, с которого началась тема, запилить от силы за пару часов.
Буквальный ответ: чем быстрее, тем лучше. Просто вы не понимаете, что требуется. Как бы мне объяснить, чем фреймворк отличается от готового продукта, купленного за большие деньги...
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, 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/
BDA>Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
BDA>
BDA>UPDATE Operations
BDA>SET Priority="High"
BDA>WHERE Client IN (SELECT Id FROM Clients WHERE City=:city);
BDA>
Нет, будет два шага, сначала запрос, потом апдейт. Собственно тоже самое, что и в БД, только немного кода надо написать. Как раз из-за мета-модели в базе.
Проблема в том, что если ты хранишь каждую версию строки в базе, то у тебя такой апдейт и не получится. У тебя будут инсерты и скорее всего больше одного, поэтому тебе надо будет сначала получить все ИДшники, а потом сделать инсерт, по сути тоже самое, только выраженное в SQL. Умножаем это на то, что у postgres нету multi-statement транзакций, только в хранимках, получаем те же яйца, только в профиль.
BDA>То есть, по сути, эти чижики взяли 5% SQL, завернули его в модный тогда XML, и вот с этим предлагается работать. BDA>Если CAML с тех пор стал поддерживать не 5% SQL, а хотя бы столько, сколько надо для выполнения указанной операции, или, может быть, сам CAML выкинули на помойку, заменив его еще каким-нибудь хренамлом, то с этого и надо начинать.
Прежде чем ругать реализуй хотябы прототип своей системы, которая хранит всю историю.
G>>Но SharePoint рассчитан именно на работ с отдельными записями, даже в режиме редактирования таблицы массовые изменения по одному отправляются на сервер, поэтому такие вещи как ты пишешь там неудобны.
BDA>Во-первых, не неудобны, а НЕВОЗМОЖНЫ. Вот, цитирую картинку. Она одна круче всяких слов: BDA>Image: updatesingle_vs_updatebatch-600x106.png
Не пойму что ты хочешь сказать. Что невозможно отправить один батч на сервер чтобы обновить много записей? Это можно сделать вообще-то.
BDA>При переходе от поэлементной обработки к пакетной НА СТА ЗАПИСЯХ ОНИ СУМЕЛИ СОКРАТИТЬ ВРЕМЯ с 4.5 СЕКУНД ДО 2.7! Рекорд, млять, для книги Гиннесса. Теперь, я думаю, те, кто это читают, поймут, что не уложиться в 30 секунд таймаута там не просто, а очень просто. А потом цикл будет просто прерван в середине, привет, неконсистентность.
Никаких 30 секунд таймаута на одну операцию с базой нет. 30 секунд есть для батча клиентской объектной модели и 60 сек общего времени для sandbox. Ни тем, ни другим, никто не заставляет тебя пользоваться.
Но это опять про танцоров. Ты для начала сделай свою систему с верионностью, чтобы было что сравнивать.
BDA>Во-вторых, именно это и делает ШП игрушкой. Зашибись: таблицы есть, а работать с табличными данными нельзя.
Работай, кто же мешает? Поэлементно, как в excel. Никто никогда и не говорил, что списки SharePoint должны быть похожи на таблицы в БД.
Для пользовательских операций — добавления, обновления, удаления элементов и фильтров по колонкам функционала более чем достаточно.
Для твоей задачи нужно что-то еще? Ты же не написал какие запросы будут.
BDA>На самом-то деле, можно, конечно. Если есть компьютер и программа, все можно, если захотеть. Я тут дурачка включил, думал, послушаю, что умные люди скажут. Но не дождавшись ничего умного, рассказываю, как это делается на самом деле. Сначала вы берете всех этих ханжей, которые говорят, что в БД лазить можно только через CAML/OM, и посылаете в большую и черную жо. Затем пишете триггеры и хранимки на SQL CLR, которые умеют маппить имена списков, с которыми вы работаете, в допусловия для WHERE при UPDATE [AllUserData]. Потом начинается самое веселое: поскольку формулы у них считаются не в хранимках, а в памяти, на C++ (да, я пытался сделать reverse engineering), то их после UPDATE все надо посчитать вручную. То есть, написать самому парсер/калькулятор языка расчетов и менеджер триггеров, чтоб он на собственные обновления не реагировал.
Я за 5 минут пишу просто на JS функцию, которая делает что нужно по нажатию кнопки. Пусть код работает 20 секунд даже, пользователю показывается нормальный попап с прогрессом.
Если пользователю не надо эту операцию делать каждые 30 секунд, то проблем никаких. А если надо, то делается очередь и уже асинхронно на сервере обрабатывается.
Проблема у тебя исключительно надуманная. Синхронно делать массовые операции в "простой таблице" — в реальности такой сценарий не существует.
Попробуй реализовать свое хранилище с версионностью на каждое изменение и сделай там массовые операции.
G>>Для CRM я бы взял dynamics crm, но там нет версионности на каждое изменение. BDA>Да, много чего можно взять, если задаться целью купить у Микрохвоста.
Тебе же прототип нужен, а CRM прекрасно работает 90 дней в триале. За 90 дней ты не сможешь сделать прототип?
SP Foundation вообще бесплатен.
Если не нравится MS, то возьми 1C. Там тоже CRM есть.
Если тебе нужен прототип, то зачем вообще программировать хранилище и UI? Возьми готовое.
G>>Но это мы опять о танцорах. А теперь давай к реальности. BDA>Реальность я описал вам выше. Но вы ее проигнрорировали. Как там поднять приоритет, а?
Да напиши код, в чем проблема? Пусть медленно работает, скрась ожидание пользователя прогресс-баром. С чего ты взял что это вообще проблема с точки зрения пользователя или бизнеса? Ты лишь пишешь, что система, которая имеет версионность на каждую запись внезапно работает медленнее при массовых апдейтах, чем СУБД без такой версионности.
>>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице) BDA>Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие.
Например? Ты же сам написал, что не хочешь генерировать таблицы? Других вариантов нет, ил ты генерируешь таблицы или хранишь все в одной.
1С, Access, CRM генерируют, но в них версионности нет, максимум лог изменений отдельных полей без отката. SP и другие CMS обычно не генерируют (бывают варианты, но чаще в одной таблице все лежит), зато чаще всего версионность есть.
>>, и тебе нужно решить ту же проблему. Найти все операции кастомеров по определенному критерию и поднять приоритет. Не забываем, что на каждую операцию и у тебя появилась новая версия. А надо бы еще не время операции не заблокировать таблицу данных на запись (ибо очень сильно ударит по быстродействию системы). Можешь хотя бы примерно описать как это сделать "транзакционно"?
BDA>Это называется «хобот в жопу». Я сюда пришел с вопросом, как это сделать — один вопрос был задан в этом форуме, второй вопрос в соседнем (про БД). Научив попутно шаропоинтщика тонкостям работы с шаропоинтом, через три итерации я встречаюсь со своим же собственным вопросом. «Вечный кайф!»
Твоя ситуация называется "думаю что знаю". Вот ты не знаешь как сделать хранилище. Ты не знаешь как устроены CMS и почему. При этом ты думаешь что знаешь почему SP плохой и как на нем делать решения. Увы, пока у тебя хобот в жопе, пока ты думаешь что знаешь, ты ничему не научишься.
Тут два варианта, или ты пойдешь учиться, или сделаешь свой прототип хранилища. Причем целенаправленная учеба займет от силы месяц part-time, а свое хранилище будешь полгода пилить фуллтайм до первого рабочего состояния. А потом наступит просветление, что 90% функций, которые ты хотел заложить, будут сильно тормозить, но в реальности не встретятся и ты получишь 5% возможностей SQL и завернешь в модный нынче JSON.
G>>Ты ушел от ответа на вопрос. Свой аналог ты сколько пилить собрался? Чтобы он и массовые операции поддерживал, и таблицы в базе не трогал (как 1С или dynamics crm), да еще и работал быстро с любыми серьезными объемами данных. G>>Ты можешь 100500 раз ругать системы типа шарика, или dynamics, или 1С, или что еще там тебе может не нравится. Но они позволят этот самый прототип, с которого началась тема, запилить от силы за пару часов.
BDA>Буквальный ответ: чем быстрее, тем лучше. Просто вы не понимаете, что требуется. Как бы мне объяснить, чем фреймворк отличается от готового продукта, купленного за большие деньги...
Ты же не рассказал что требуется. Все что ты сказал — версионность каждого изменения и конструктор для списков с простыми полями. Бесплатный SP делает именно это.
А с нуля пилить такое у тебя займет ооооооочень долго, что как-то не соответствует идее создания прототипа.
Re[10]: Какие фреймворки использовать для прототипа?
Здравствуйте, gandjustas, Вы писали:
BDA>>Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
BDA>>
BDA>>UPDATE Operations
BDA>>SET Priority="High"
BDA>>WHERE Client IN (SELECT Id FROM Clients WHERE City=:city);
BDA>>
G>Нет, будет два шага, сначала запрос, потом апдейт. Собственно тоже самое, что и в БД, только немного кода надо написать. Как раз из-за мета-модели в базе.
Так ведь это — принципиальная разница. Я не знаю, помните ли вы, как SQL-сервера боролись с продуктами типа dBase, FoxBase, Clipper. Было это 20 лет назад. Я был молод, но поскольку читал правильную прессу, этот момент очень хорошо отследил. Дибейзовщина именно так и была устроена («сначала запрос, потом апдейт») и просрала все полимеры по следующим причинам:
1. Канал между СУ и клиентами был перегружен. По мере роста нагрузки сеть забивалась, люди ставили более мощное сетевое оборудование, но рост пропускной способности имел лимит в несколько раз. Когда этот лимит был исчерпан, клиенты (т.н. АРМы) начинали проводить время в ожидании и СДЕЛАТЬ НЕЛЬЗЯ БЫЛО НИЧЕГО.
2. Пока осуществлялся запрос, другие могли взять и выполнить апдейт, приводя базу в неконсистентное состояние.
3. Пытаясь пофиксить п. 2, разработчики лочили базу, в результате чего каждый клиент становился узким местом.
SQL решил все эти проблемы одним махом.
1. После того, как данные перестали гоняться на сервер, нагрузка упала на много-много десятичных порядков. Сравните байты и килобайты запросов и мегабайты и гигабайты данных, которые ходят туда и обратно.
2. Запрос транзакционен и консистентность гарантируется.
3. Ни один клиент не мог быть больше узким местом.
Шаропоинт, по сути своей, это Дибейз наших дней. Все заточено под архитектуру, которая была заведомо проигравшей 20 лет назад. Если история кого-то ничему не учит, то он будет наступать на грабли, пока не поумнеет. Причем, в оправдание Шаропоинта можно сказать, что его, может быть, никогда и не проектировали ни под какую серьезную работу с данными. Схема «один специально обученный человек ведет списки, все остальные читают» — потолок его табличных возможностей. Создатели его и не продвигают для решения таких задач, как я описал. А вы — продвигаете. Не понимаю, зачем я трачу время на то, чтобы вправить мозги одному-единственному человеку, когда я ищу кого-нибудь, кто мне самому мозги бы вправил.
G>Проблема в том, что если ты хранишь каждую версию строки в базе, то у тебя такой апдейт и не получится. У тебя будут инсерты и скорее всего больше одного, поэтому тебе надо будет сначала получить все ИДшники, а потом сделать инсерт, по сути тоже самое, только выраженное в SQL. Умножаем это на то, что у postgres нету multi-statement транзакций, только в хранимках, получаем те же яйца, только в профиль.
... G>Прежде чем ругать реализуй хотябы прототип своей системы, которая хранит всю историю.
... G>Но это опять про танцоров. Ты для начала сделай свою систему с верионностью, чтобы было что сравнивать.
Так вот, про вправку мозгов. Я не знаю, как это сделать даже без версионности, чтобы тех граблей, как в Шарике не было, и я ищу кого-нибудь, кто лучше меня и вас разбирается в обработке данных, и подскажет какую-нибудь идейку.
В чистом итоге пока следующее. Готовых решений нет. ORM точно не нужен. Можно попробовать паттерн EAV. Можно попробовать сделать sparse-колонки. Можно мапить таблицы 1:1 и по мере роста их числа прибегнуть к шардингу.
BDA>>Во-первых, не неудобны, а НЕВОЗМОЖНЫ. Вот, цитирую картинку. Она одна круче всяких слов: BDA>>[--url=http://apmblog.dynatrace.com/wp-content/updatesingle_vs_updatebatch-600x106.png]Image: updatesingle_vs_updatebatch-600x106.png[/url] G>Не пойму что ты хочешь сказать. Что невозможно отправить один батч на сервер чтобы обновить много записей? Это можно сделать вообще-то. G>Никаких 30 секунд таймаута на одну операцию с базой нет. 30 секунд есть для батча клиентской объектной модели и 60 сек общего времени для sandbox. Ни тем, ни другим, никто не заставляет тебя пользоваться.
Что вы не понимаете? Что система, которая на 100 записях при ПАКЕТНОЙ обработке данных (то есть, правильно написанном запросе) заставляет клиента ждать по 2 секунды, немного не то, что нужно для решения практических задач? Не понимаете — и не понимайте, мне вообще пофиг.
BDA>>На самом-то деле, можно, конечно. Если есть компьютер и программа, все можно, если захотеть. Я тут дурачка включил, думал, послушаю, что умные люди скажут. Но не дождавшись ничего умного, рассказываю, как это делается на самом деле. Сначала вы берете всех этих ханжей, которые говорят, что в БД лазить можно только через CAML/OM, и посылаете в большую и черную жо. Затем пишете триггеры и хранимки на SQL CLR, которые умеют маппить имена списков, с которыми вы работаете, в допусловия для WHERE при UPDATE [AllUserData]. Потом начинается самое веселое: поскольку формулы у них считаются не в хранимках, а в памяти, на C++ (да, я пытался сделать reverse engineering), то их после UPDATE все надо посчитать вручную. То есть, написать самому парсер/калькулятор языка расчетов и менеджер триггеров, чтоб он на собственные обновления не реагировал. G>
Вы зря смеетесь, потому, что это было и остается единственным решением, которое позволяет людям, вляпавшимся в это Г, хоть как-то работать. Поскольку я, даже не имея исходников, поменял механизм работы с «дибейзовского» на «скульный», превратив Шаропоинт в истинно клиент-серверный продукт. Ничего более хакерского я в своей жизни не делал, а по сложности это сравнимо с заменой двигателя автомобиля на полном ходу. Впрочем, не буду мешать, поскольку чтобы понять весь пафос, надо хоть какую-то культуру обработки данных иметь, а из этого:
G>Я за 5 минут пишу просто на JS функцию, которая делает что нужно по нажатию кнопки. Пусть код работает 20 секунд даже, пользователю показывается нормальный попап с прогрессом.
видно, что вы даже суть SQL не понимаете.
Я хочу подчеркнуть, что я сюда пришел за советом, поскольку не знаю, как свою задачу решить, а не чтобы кого-то попинать. Дорогое удовольствие вас пинать, поскольку времени вагон нужен. И в дальнейшем пинайте себя сами, а я буду общаться только на тему своей задачи. Можете считать ее надуманной, пожалуйста, раз вы так лихо делите транзакцию на запрос и апдейт, и производите обработку данных на клиенте, вы ее и не поймете никогда.
>>>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице) BDA>>Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие. G>Например? Ты же сам написал, что не хочешь генерировать таблицы? Других вариантов нет, ил ты генерируешь таблицы или хранишь все в одной.
Например, отказаться от табличных СУБД.
Дальше скипаю, перехожу к сути:
G>А с нуля пилить такое у тебя займет ооооооочень долго, что как-то не соответствует идее создания прототипа.
Если не пилить свой язык запросов, свою ОМ, свой API, и все остальное, что напилили в ШП, а ограничиться задачей, которую я достаточно подробно описал (очень простая виртуальная БД, но написанная не через жопу... то есть, клиентский код, как ШП), то ее решение и будет прототипом, который можно создать относительно малыми силами. Дальше можно прикрутить к нему мои специфические хотелки.
Re[11]: Какие фреймворки использовать для прототипа?
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Здравствуйте, gandjustas, Вы писали:
BDA>>>Может, вы вопрос мой прочитаете сначала? SPWeb.ProcessBatchData принимает на вход CAML, а в его <Batch> вы такое сложное условие не нарисуете:
BDA>>>
BDA>>>UPDATE Operations
BDA>>>SET Priority="High"
BDA>>>WHERE Client IN (SELECT Id FROM Clients WHERE City=:city);
BDA>>>
G>>Нет, будет два шага, сначала запрос, потом апдейт. Собственно тоже самое, что и в БД, только немного кода надо написать. Как раз из-за мета-модели в базе.
BDA>Так ведь это — принципиальная разница...
Все это нерелевантно предмету обсуждения.
BDA>1. После того, как данные перестали гоняться на сервер, нагрузка упала на много-много десятичных порядков. Сравните байты и килобайты запросов и мегабайты и гигабайты данных, которые ходят туда и обратно. BDA>2. Запрос транзакционен и консистентность гарантируется.
Когда речь идет о прототипе, то какая разница?
BDA>3. Ни один клиент не мог быть больше узким местом.
Это вообще ортогонально способу делать апдейты. Залочить базу или основные рабочие таблицы можно и SQL Server, особенно если мета-модели в базе.
BDA>Шаропоинт, по сути своей, это Дибейз наших дней. Все заточено под архитектуру, которая была заведомо проигравшей 20 лет назад. Если история кого-то ничему не учит, то он будет наступать на грабли, пока не поумнеет. Причем, в оправдание Шаропоинта можно сказать, что его, может быть, никогда и не проектировали ни под какую серьезную работу с данными. Схема «один специально обученный человек ведет списки, все остальные читают» — потолок его табличных возможностей. Создатели его и не продвигают для решения таких задач, как я описал. А вы — продвигаете. Не понимаю, зачем я трачу время на то, чтобы вправить мозги одному-единственному человеку, когда я ищу кого-нибудь, кто мне самому мозги бы вправил.
Это лишь твое мнение, никому кроме тебя не нужное. Есть проблема сделать прототип с простыми списками и полями — SP подходит. Все апелляции к архитектуре — ни о чем. Аргумент о том, что нельзя сделать массовый апдейт одним запросом тоже ни о чем, есть 100500 способов получить аналогичный результат, и они все подходят для прототипа.
G>>Проблема в том, что если ты хранишь каждую версию строки в базе, то у тебя такой апдейт и не получится. У тебя будут инсерты и скорее всего больше одного, поэтому тебе надо будет сначала получить все ИДшники, а потом сделать инсерт, по сути тоже самое, только выраженное в SQL. Умножаем это на то, что у postgres нету multi-statement транзакций, только в хранимках, получаем те же яйца, только в профиль. BDA>... G>>Прежде чем ругать реализуй хотябы прототип своей системы, которая хранит всю историю. BDA>... G>>Но это опять про танцоров. Ты для начала сделай свою систему с верионностью, чтобы было что сравнивать.
BDA>Я не знаю, как это сделать даже без версионности, чтобы тех граблей, как в Шарике не было
При этом у шарика хреновая архитектура... ну да, мы поняли.
BDA>В чистом итоге пока следующее. Готовых решений нет. ORM точно не нужен. Можно попробовать паттерн EAV. Можно попробовать сделать sparse-колонки. Можно мапить таблицы 1:1 и по мере роста их числа прибегнуть к шардингу.
Ты не о том думаешь. Ты лучше думай о версионности, как сделать чтобы каждый апдейт создавал новую запись и не ломал связи. А как придумаешь, тогда попробуй сделать массовый апдейт, чтобы он не лочил всю базу и сохранял консистентность\независимость транзакций. А уже потом на это накручивай flexible schema. Только вот прототип будет нескоро...
BDA>Что вы не понимаете? Что система, которая на 100 записях при ПАКЕТНОЙ обработке данных (то есть, правильно написанном запросе) заставляет клиента ждать по 2 секунды, немного не то, что нужно для решения практических задач? Не понимаете — и не понимайте, мне вообще пофиг.
Я не знаю что там за система, я видел и обычные реляционные схемы, которые по 5 сек работают на одиночном апдейте работают. 20 мс на обработку одной записи с правами и версионностью — вполне ок. Считаешь что это медленно — сделай быстрее.
BDA>Вы зря смеетесь, потому, что это было и остается единственным решением, которое позволяет людям, вляпавшимся в это Г, хоть как-то работать. Поскольку я, даже не имея исходников, поменял механизм работы с «дибейзовского» на «скульный», превратив Шаропоинт в истинно клиент-серверный продукт. Ничего более хакерского я в своей жизни не делал, а по сложности это сравнимо с заменой двигателя автомобиля на полном ходу. Впрочем, не буду мешать, поскольку чтобы понять весь пафос, надо хоть какую-то культуру обработки данных иметь, а из этого:
Я совсем не зря смеюсь, потом что большего бреда я вообще не слышал. Ты потратил много денег клиента, привел его ферму в неподдерживаемое состояние (апдейты не поставишь, как апгрейдить — неясно, в поддержку МС звонить бесполезно). В итоге экономический эффект от твоих действий — отрицательный, то есть насрал больше, чем пользы принес. И ты еще умудряешься этим гордиться. И самое главное, что твои действия можно было бы заменить несколькими строками JS, да они еще и лучше работали бы.
G>>Я за 5 минут пишу просто на JS функцию, которая делает что нужно по нажатию кнопки. Пусть код работает 20 секунд даже, пользователю показывается нормальный попап с прогрессом. BDA>видно, что вы даже суть SQL не понимаете.
Видимо я получше тебя понимаю, причем не только SQL, но и потребности пользователей и бизнес.
>>>>Вот у тебя есть postgres, какая-то база с метаданными (по сути все данные хранятся в одной таблице) BDA>>>Не «по сути», а «одно из возможных решений». Я поинтересовался, есть и другие. G>>Например? Ты же сам написал, что не хочешь генерировать таблицы? Других вариантов нет, ил ты генерируешь таблицы или хранишь все в одной.
BDA>Например, отказаться от табличных СУБД.
Если ты пользователю выставляешь таблицы со связями, то как ты будешь джоины делать?
Тебе вообще зачем такая база? Ты какую бизнес-задачу решаешь?
BDA>Дальше скипаю, перехожу к сути:
G>>А с нуля пилить такое у тебя займет ооооооочень долго, что как-то не соответствует идее создания прототипа.
BDA>Если не пилить свой язык запросов, свою ОМ, свой API, и все остальное, что напилили в ШП, а ограничиться задачей, которую я достаточно подробно описал (очень простая виртуальная БД, но написанная не через жопу... то есть, клиентский код, как ШП), то ее решение и будет прототипом, который можно создать относительно малыми силами. Дальше можно прикрутить к нему мои специфические хотелки.
Прототипом чего?
