Здравствуйте, Sinclair, Вы писали:
Z>>Мнк сложно описать эти проблемы не приводя в пример килобайты кода, схему данных, требования. Вполне возможно это неправильная готовка. Некоторые проблемы с реюзом запросов мог бы решить linq, но мне нужна поддержка oracle и firebird, так что как орм он не может быть использован. S>А, ну тогда спорить не о чем. Без linq анемика начинает очень жестко сосать — ей нужен адекватный язык для выражения запросов. Рич модель обходит эту тему с тыла, предлагая навигацию+LL.
Если в линк будут добавлены DML операции и провайдеры хотя бы к Oracle и DB2, а лучше к большинству промышленных RDBMS true anemic model будет очень и очень хороша. Я бы даже придумал ей другое название, чтобы отличать от ADM которая не RDM лишь по признаку отсутствия логики в классах. Предлагаю Data Centric Domain Model (DCDM).
Мне очень нравится подход, работы напрямую с базой, где объекты модели лишь выполняют функцию DTO.
Впрочем если nh2linq наконец переделают на генерацию AST SQL вместо генерации критериев, к нему будет иметь смысл прикрутить те же DML и использовать stateless session. В итоге получим crossDb и crossCache из коробки, плюс богатый мэппинг. (про нужность кеша и мэппинга можно не возражать, я знаю твое мнение
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[13]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Ziaw, Вы писали:
Z>Если в линк будут добавлены DML операции и провайдеры хотя бы к Oracle и DB2, а лучше к большинству промышленных RDBMS true anemic model будет очень и очень хороша. Я бы даже придумал ей другое название, чтобы отличать от ADM которая не RDM лишь по признаку отсутствия логики в классах. Предлагаю Data Centric Domain Model (DCDM).
Ну, надежда на это велика весьма есть — см. опять же на IQToolkit.
Z>Мне очень нравится подход, работы напрямую с базой, где объекты модели лишь выполняют функцию DTO.
Z>Впрочем если nh2linq наконец переделают на генерацию AST SQL вместо генерации критериев, к нему будет иметь смысл прикрутить те же DML и использовать stateless session. В итоге получим crossDb и crossCache из коробки, плюс богатый мэппинг. (про нужность кеша и мэппинга можно не возражать, я знаю твое мнение
Автор linq2hn прямо сейчас полощет мозг команде С# (на пару с автором linq2llblgen) насчёт умения правильно готовить. По сравнению с этими парнями VladD2 — просто синоним галантности. Я бы предложил ему заняться "переделкой на генерацию AST SQL", но боюсь попасть под горячую руку.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Sinclair, Вы писали:
S>Автор linq2hn прямо сейчас полощет мозг команде С# (на пару с автором linq2llblgen) насчёт умения правильно готовить. По сравнению с этими парнями VladD2 — просто синоним галантности.
Ayende? Тоже требует ввода присваивания в экспрешены?
S>Я бы предложил ему заняться "переделкой на генерацию AST SQL", но боюсь попасть под горячую руку.
Прошу прощения, AST HQL, иначе никакого crossDb не выйдет. Парсер hql теперь генерит AST HQL, вместо генерации сиквела, так что принципиальная возможность генерации его же из експрешенов уже есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[15]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Ziaw, Вы писали:
Z>Прошу прощения, AST HQL, иначе никакого crossDb не выйдет. Парсер hql теперь генерит AST HQL, вместо генерации сиквела, так что принципиальная возможность генерации его же из експрешенов уже есть.
Поясню, раньше развитие linq2nh уперлось в плохо расширяемый и неполный синтаксис ICriteria (QueryObject by hibernate). Я даже сам пытался переделать провайдер на генерацию hql, но генерация текста малоприятное занятие и, оценив объем, я отказался от продолжения. Теперь можно генерить hql в виде дерева выражений, так что я очень надеюсь, что преобразователь ExressionTree -> HqlTree не за горами.
В свете введения update & delete в hql DML будет сделать не слишком сложно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[15]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Ziaw, Вы писали:
Z>Ayende? Тоже требует ввода присваивания в экспрешены?
Проще, они просят MS поделиться опытом написания LINQ провайдеров. Как выясняется — вообще нифига не тривиальная штука, по разным причинам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[16]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, IB, Вы писали:
IB>Проще, они просят MS поделиться опытом написания LINQ провайдеров. Как выясняется — вообще нифига не тривиальная штука, по разным причинам.
Даже реверс инженеринг кода не помогает? Черт, плохие новости
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[17]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, IB, Вы писали:
IB>>Проще, они просят MS поделиться опытом написания LINQ провайдеров. Как выясняется — вообще нифига не тривиальная штука, по разным причинам.
Z>Даже реверс инженеринг кода не помогает? Черт, плохие новости
А сам не пробововал?
Я вот сгоряча полез Linq2SQL реверсинженирить, захотел найти какой-нить способ DML туда прикрутить.
Забросил быстро, много там всего.
Re[18]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, gandjustas, Вы писали:
G>А сам не пробововал?
Реверсить не пробовал, пробовал писать свой провайдер для HQL.
Основные проблемы были в том, что идет генерация текста, а не другого expression tree, решал генерацией промежуточного ET, по которому генерил текст. Основная проблема — много там всего, одному мне не поднять. У линка есть офигенный слой генерации сиквела который уже есть в NH, обкатан и работает. Поэтому провайдер должен быть проще чем сам линк.
G>Забросил быстро, много там всего.
Ага, но этож не концептуальная проблема. Тем более им не нужен слой генерации сиквела, может быть он там размазан?
... << RSDN@Home 1.2.0 alpha 4 rev. 1176>>
Re[7]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, meowth, Вы писали: M>Да. Там 9 страниц, со второй начинается интересное: "The Cost of GUIDs as Primary Keys", http://www.informit.com/articles/article.aspx?p=25862
Полная херня. Интересное начинается с седьмой, и на ней же и заканчивается.
1. Как показал чувак, при чтениях GUID проигрывает всего 10% по сравнению с интом. Это, скорее, аргумент в пользу, чем против.
2. Падение производительности в 10 раз на вставках ничего не показывает. Поясняю почему:
2.1. отношение размера ключа к размеру данных фантастически велико — он сам это признаёт.
2.2. эксперимент ставился в условиях "один клиент хреначит много данных". Конечно же, в этом случае разбрасывание PK по разным страницам даст негативный эффект. В реальной жизни, где вставка ведется во многих параллельных транзакциях, это даст обратный эффект — благодаря тому, что блокировки будут более равномерно размазаны по страницам.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, meowth, Вы писали:
M>Ой-ёй, только не guid =) Он слишком рандомный; это убивает индекс, и MS-SQL плохо на них реагирует (низкой производительностью).
Ничего подобного. С производительностью все хорошо и с индексами тоже, если в реальной жизни пользоваться а не синтетические тесты гонять.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[8]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, Sinclair, Вы писали:
S>Полная херня.
Постараюсь запомнить этот аргумент как довод более опытного разработчика, спасибо.
S>Интересное начинается с седьмой, и на ней же и заканчивается. S>1. Как показал чувак, при чтениях GUID проигрывает всего 10% по сравнению с интом. Это, скорее, аргумент в пользу, чем против.
Безотносительно остального окружения, то, что он проигрывает -- это плюс? Поясните в этом контексте, пожалуйста.
S>2. Падение производительности в 10 раз на вставках ничего не показывает. Поясняю почему: S>2.1. отношение размера ключа к размеру данных фантастически велико — он сам это признаёт.
Т.е. вы априори считаете, что дело просто в размере пакета с данными (guid "ширше"), так?
S>2.2. эксперимент ставился в условиях "один клиент хреначит много данных". Конечно же, в этом случае разбрасывание PK по разным страницам даст негативный эффект. В реальной жизни, где вставка ведется во многих параллельных транзакциях, это даст обратный эффект — благодаря тому, что блокировки будут более равномерно размазаны по страницам.
Ваша правда в рассуждениях, и на ней я основывался, когда пояснял, что "guid.comb" как алгоритм лучше, чем sequence распределяет блокировки, но не бросается хаотически по страницам, как чистый guid.
Также в правильно организованной сесси NHibernate вставка осуществляется "пачкой" (в commitе), в этом случае появляется как раз ситуация "клиент хреначит многоданные". Использование guid.comb здесь имхо оправдано как по сравнению с sequence, так и с original guid.
Re[9]: Архитектура приложения с несколькими клиентами и одни
Здравствуйте, meowth, Вы писали: S>>Полная херня. M>Постараюсь запомнить этот аргумент как довод более опытного разработчика, спасибо.
Это не довод. Это тезис, который аргументируется далее по ходу поста.
M>Безотносительно остального окружения, то, что он проигрывает -- это плюс? Поясните в этом контексте, пожалуйста.
Поясняю: четырёхкратное увеличение размера ключа приводит всего лишь к 10% проигрышу в производительности, при значительном увеличении удобства использования. Вот это увеличение трудно измерить; каждый делает выводы для себя. Если лично в вашем случае GUID будет удобнее INT хотя бы на 15% — то этот эксперимент явно свидетельствует в его пользу.
M>Т.е. вы априори считаете, что дело просто в размере пакета с данными (guid "ширше"), так?
Нет, я априори считаю, что в данных условиях роль индекса при вставке чрезмерна — по сравнению с реальным сценарием. Поэтому любые замедления, связанные с индексом, очень сильно отражаются на общем результате. В реальных сценариях вставка данных будет весить больше, и замедление индексных вставок будет не столь заметным.
M>Ваша правда в рассуждениях, и на ней я основывался, когда пояснял, что "guid.comb" как алгоритм лучше, чем sequence распределяет блокировки, но не бросается хаотически по страницам, как чистый guid.
Я не уверен, что цена в реальных сценариях будет настолько высока, чтобы оправдать приседания с самостоятельной генерацией GUID. Лично мне вот неочевидно, где гарантии уникальности сформированного таким образом GUID. M>Также в правильно организованной сесси NHibernate вставка осуществляется "пачкой" (в commitе), в этом случае появляется как раз ситуация "клиент хреначит многоданные". Использование guid.comb здесь имхо оправдано как по сравнению с sequence, так и с original guid.
NHibernate мог бы в таких случаях переходить на UuidCreateSequential и иметь гарантии как уникальности, так и упорядоченности, безо всяких наколенных "алгоритмов".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Sinclair, Вы писали:
S>Поясняю: четырёхкратное увеличение размера ключа приводит всего лишь к 10% проигрышу в производительности, при значительном увеличении удобства использования. Вот это увеличение трудно измерить; каждый делает выводы для себя. Если лично в вашем случае GUID будет удобнее INT хотя бы на 15% — то этот эксперимент явно свидетельствует в его пользу.
Так я и не спорю. При выборе между типом поля для Id из guid и int я выберу guid, мне тоже так удобнее.Мне только не нравится алгоритм генерации.
S>Я не уверен, что цена в реальных сценариях будет настолько высока, чтобы оправдать приседания с самостоятельной генерацией GUID. Лично мне вот неочевидно, где гарантии уникальности сформированного таким образом GUID.
Никаких приседаний, Nhibernate занимается им самостоятельно.
Гарантия уникальности основана на следующем:
Пример:
E25AFE33-DB2D-4502-9BF0-919001862D20
83E689D3-8549-4094-B223-919001862D20
CC22A56D-0CD5-43C5-990E-919001862D20
D5149998-1718-468C-B1AD-919001862D20
CBD0182D-4A0E-40AC-9A4C-919001862D20
Левые 20 16ричных разрядов уникальны, т.е. вероятность их повторения 1/(16^20) = 8.3e-25.
С другой стороны, новый полностью уникальный guid (левая часть) не может генериться чаще, чем примерно 300 в секунду. Т.е. для того, чтобы получить неуникальный uid, нужно вставить не менее, чем 8.3e-25 * 300 = ~2.5e19 записей в секунду.
Как-то так.
S>NHibernate мог бы в таких случаях переходить на UuidCreateSequential и иметь гарантии как уникальности, так и упорядоченности, безо всяких наколенных "алгоритмов".
В таком случае есть следующая проблема: если мы перекладываем генерацию uid на БД, то а) мы обязаны вставлять записи по одной (увеличивая количество round-trips) и подтягивать потом Id назад в ORM (через SCOPE_IDENTITY()) б) смысл UoW теряется, потому что мы обязаны вставлять записи сразу, как только мы их добавили в UoW, а также держать открытой транзакцию (на случай, если захотим откатить) дольше, чем если бы это делалось batch insert.
Здравствуйте, meowth, Вы писали:
M>Никаких приседаний, Nhibernate занимается им самостоятельно.
M>Гарантия уникальности основана на следующем: M>Пример: M>E25AFE33-DB2D-4502-9BF0-919001862D20 M>83E689D3-8549-4094-B223-919001862D20 M>CC22A56D-0CD5-43C5-990E-919001862D20 M>D5149998-1718-468C-B1AD-919001862D20 M>CBD0182D-4A0E-40AC-9A4C-919001862D20 M>Левые 20 16ричных разрядов уникальны, т.е. вероятность их повторения 1/(16^20) = 8.3e-25.
Это хреновая гарантия. Вообще, все алгоритмы генерации GUID хорошо известны и тщательно продуманы. Для них известны некоторые свойства. Мне не нравится идея переходить от обоснованных алгоритмов к самописаным без должного основания. Нет, я понимаю, что это не магия, но тем не менее.
S>>NHibernate мог бы в таких случаях переходить на UuidCreateSequential и иметь гарантии как уникальности, так и упорядоченности, безо всяких наколенных "алгоритмов".
M>В таком случае есть следующая проблема: если мы перекладываем генерацию uid на БД, то а) мы обязаны вставлять записи по одной (увеличивая количество round-trips) и подтягивать потом Id назад в ORM (через SCOPE_IDENTITY()) б) смысл UoW теряется, потому что мы обязаны вставлять записи сразу, как только мы их добавили в UoW, а также держать открытой транзакцию (на случай, если захотим откатить) дольше, чем если бы это делалось batch insert.
Ничего не понимаю. Зачем нам перекладывать генерацию на БД? Основное преимущество GUID — возможность распределённой генерации. Ну так и надо им пользоваться. Пусть гибернейт не страдает фигнёй, а пользует документированный UuidCreateSequential().
M>Кроме того, в MsSQL2005 и MsSQL2008 SCOPE_IDENTITY() и @@INDETITY() слегка "поломатые". https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=328811
Это вообще не имеет отношения к проблемам GUID.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Sinclair, Вы писали:
S>Ничего не понимаю. Зачем нам перекладывать генерацию на БД? Основное преимущество GUID — возможность распределённой генерации. Ну так и надо им пользоваться. Пусть гибернейт не страдает фигнёй, а пользует документированный UuidCreateSequential().
Не волнуйтесь, это тоже поддерживается.
Хотя, согласно вашим рассуждениям, это в реальности ни на что не влияет, у меня тем не менее вопрос -- насколько такой guid будет index-friendly?
M>>Кроме того, в MsSQL2005 и MsSQL2008 SCOPE_IDENTITY() и @@INDETITY() слегка "поломатые". https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=328811 S>Это вообще не имеет отношения к проблемам GUID.
Это имело отношение к предположению, что ведется выборка сгенерированного uid'а из БД, которое оказалось преждевременным
Re[13]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали: M>Хотя, согласно вашим рассуждениям, это в реальности ни на что не влияет, у меня тем не менее вопрос -- насколько такой guid будет index-friendly?
В той же статье на той же странице приведен листинг 3. Это и есть те GUID, которые возвращаются UuidCreateSequential(). Именно их пытается эмулировать автор статьи при помощи наколеночного алгоритма.
M>Это имело отношение к предположению, что ведется выборка сгенерированного uid'а из БД, которое оказалось преждевременным
Обе функции не имеют никакого отношения к выборке сгенерированного UID из БД.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Sinclair, Вы писали:
M>>Хотя, согласно вашим рассуждениям, это в реальности ни на что не влияет, у меня тем не менее вопрос -- насколько такой guid будет index-friendly? S>В той же статье на той же странице приведен листинг 3. Это и есть те GUID, которые возвращаются UuidCreateSequential(). Именно их пытается эмулировать автор статьи при помощи наколеночного алгоритма.
Вопрос остается в силе. Обратите, пожалуйста, внимание на то, чем отличаются эти серии guidов. В предыдущем постах и вы, и я согласились, что sequential-like uuid плохо дружит с блокировками в параллельных транзакциях. Это именно то, что мы видим в UuidSequential.
Guid.Comb:
E25AFE33-DB2D-4502-9BF0-919001862D20
83E689D3-8549-4094-B223-919001862D20
CC22A56D-0CD5-43C5-990E-919001862D20
D5149998-1718-468C-B1AD-919001862D20
CBD0182D-4A0E-40AC-9A4C-919001862D20
M>>Это имело отношение к предположению, что ведется выборка сгенерированного uid'а из БД, которое оказалось преждевременным S>Обе функции не имеют никакого отношения к выборке сгенерированного UID из БД.
Извините мою непонятливость, но хотелось бы услышать, каким образом вы выбирали бы только что сгенерированный базой identity (в предположении, что uuid генерятся базой)
Re[15]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали:
M>Вопрос остается в силе. Обратите, пожалуйста, внимание на то, чем отличаются эти серии guidов. В предыдущем постах и вы, и я согласились, что sequential-like uuid плохо дружит с блокировками в параллельных транзакциях. Это именно то, что мы видим в UuidSequential.
M>UuidCreateSequential: M>B3BFC6B1-05A2-11D6-9FBA-00C04FF317DF M>B3BFC6B2-05A2-11D6-9FBA-00C04FF317DF M>B3BFC6B3-05A2-11D6-9FBA-00C04FF317DF M>B3BFC6B4-05A2-11D6-9FBA-00C04FF317DF M>B3BFC6B5-05A2-11D6-9FBA-00C04FF317DF
M>Guid.Comb: M>E25AFE33-DB2D-4502-9BF0-919001862D20 M>83E689D3-8549-4094-B223-919001862D20 M>CC22A56D-0CD5-43C5-990E-919001862D20 M>D5149998-1718-468C-B1AD-919001862D20 M>CBD0182D-4A0E-40AC-9A4C-919001862D20
Гм. Еще раз читаем статью.
Then I found out that it wasn't the first (high) byte that was important for the new ordering, but the last (low) bytes
.
Парень добился улучшения, генерируя одинаковые правые байты, что выполняется и для sequential гуидов — там MAC адрес платы клиента.
S>>Обе функции не имеют никакого отношения к выборке сгенерированного UID из БД. M>Извините мою непонятливость, но хотелось бы услышать, каким образом вы выбирали бы только что сгенерированный базой identity (в предположении, что uuid генерятся базой)
Я, конечно, давно ничего не писал на SQL, но по-памяти будет примерно так:
create table mytable
(
ID uniqueidentifier not null primary key default (NEWID()),
varchar(max) Name
)
GO
insert into mytable(Name) values('Пётр Cаныч') output inserted.ID
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, Sinclair, Вы писали:
S>Гм. Еще раз читаем статью. S>
Then I found out that it wasn't the first (high) byte that was important for the new ordering, but the last (low) bytes
. S>Парень добился улучшения, генерируя одинаковые правые байты, что выполняется и для sequential гуидов — там MAC адрес платы клиента.
Ладно, в любом случае надо будет тестировать этот вопрос в ситуации с "многотранзакций", чтобы детально ответить на вопрос о частоте коллизий при блокировках у обоих алгоритмов.
S>Я, конечно, давно ничего не писал на SQL, но по-памяти будет примерно так: S>
S>create table mytable
S>(
S> ID uniqueidentifier not null primary key default (NEWID()),
S> varchar(max) Name
S>)
S>GO
S>insert into mytable(Name) values('Пётр Cаныч') output inserted.ID
S>
К сожалению, MsSQL >= 2005.
Re[17]: Архитектура приложения с несколькими клиентами и одн
Здравствуйте, meowth, Вы писали: M>Ладно, в любом случае надо будет тестировать этот вопрос в ситуации с "многотранзакций", чтобы детально ответить на вопрос о частоте коллизий при блокировках у обоих алгоритмов.
А, да, точно — мы же говорим об апп.сервере; тогда, действительно, начнутся коллизии из-за постоянства правых частей. Техника будет нормально работать для двузвенки. В трёхзвенке надо мерить всё отдельно.
M>К сожалению, MsSQL >= 2005.
Ну для < 2005 этот синтаксис и не работает.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мы уже победили, просто это еще не так заметно...
