Цитата(jonie @ 26.3.2009, 01:52  ) |
| 4) заменить id на GUID-ы и не мучаться с автоинкрементом |
Спорное решение. С некоторых пор я с опаской отношусь к использованию Guid'ов.
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Базы данных под .NET > синхронизация базы КПК (sdf) и ПК (mdf) |
| Автор: vutsh 25.3.2009, 11:08 |
| Добрый день!!! При синхронизации базы КПК (sdf) и ПК (mdf) вышли трудности, относительно связей. На КПК создаём клиента (он создался под ид 5), далее создаём компанию (он создался под ид 5123) где указано что оно связано с клиентом под ид 5. Далее пересылаем это всё на ПК (передача осуществляеться инсерты, которые в xml-ке), там исполняется запрос (инсерт) и клиент получается под ид уже НЕ 5, а 8791 вот...и когда мы исполняем (инсерт) для компании то оно говорит мол под ид 5 нечего нету, ну и естественно вываливается ошибка. Может кто сталкивался с такой проблемо? или знаеть какие нибудь утилы для синхронихации. Жду ответов... |
| Автор: PashaPash 25.3.2009, 11:53 |
| vutsh, есть 2 старндартных способа: 1. Обычная репликация SQL Server. http://msdn.microsoft.com/en-us/library/ms152568.aspx 2. Sync services for ADO.NET: http://msdn.microsoft.com/en-us/library/bb726002.aspx |
| Автор: jonie 25.3.2009, 21:52 |
| 3) SET INSERT_IDENTITY ON 4) заменить id на GUID-ы и не мучаться с автоинкрементом |
| Автор: Idsa 25.3.2009, 21:59 | ||
Спорное решение. С некоторых пор я с опаской отношусь к использованию Guid'ов. |
| Автор: jonie 25.3.2009, 22:13 |
| и чем же они так тебя напугали? |
| Автор: PashaPash 25.3.2009, 22:21 |
| jonie, 1. отлаживать неудобно 2. индексы по ним много кушают и тормозят 3. про NEWSEQUENTIALID() даже management studio не знает Обычный подход - rowguid, и int identity not for replication в качестве PK. Делается автоматом самой студией при настройке репликации с SQL. Более того, в конце management studio код для старта репликации под compact framework выдает...надо только копипастнуть |
| Автор: Idsa 25.3.2009, 22:50 |
jonie, ууу. Это долгая история  Работал я над одним замечательным web-проектом. На этапе проектирования по каким-то причинам (которые мне так и не удалось выяснить) было решено использовать Guid'ы. Как потом оказалось, смысла в этом не было: можно было легко обойтись автоинкрементным id. А между тем Guid'ы: 1. В четыре раза тяжелее int 2. Почем зря фрагментируют индексы. Guid'ы генерировались из .NET'а, поэтому использовать NewSequentiald не было возможности. Хотя можно было прикрутить какой-нибудь workaround вроде http://developmenttips.blogspot.com/2008/03/generate-sequential-guids-for-sql.html, но он тоже неидеален 3. Т. к. проект представлял собой Web-приложение, Guid'ы частенько использовались в качестве Get-параметров, поэтому строка запроса даже при одном параметре (не говоря уже о двух и более) выглядела очень некрасиво. Пользователи пугались. В итоге я решил взять на себя ответственность перевести базу на int'ы. Параллельно решил исправить несколько архитектурных (своих  ) багов (хоят, скорее, первопричиной изменений стали именно эти баги, а переход на int'ы стал следствием). Даже несмотря на то, что DAL реализовывался при помощи Entity Framework, переписывать пришлось кучу рутинного кода: приведение типов, Asp.net баиндинг и т. д. Конечно, большинство ошибок исправлялось при помощи Find&Replace... но попариться мне пришлось крепко: все-таки исправить около 1200 ошибок компиляции (да-да, проект был уже далеко не начальном этапе развития) - это не шутки. Я сел вечером в пятницу, закончил вечером воскресенья (вносил изменения в выходные, пока остальные не работали над кодом). Давно я так не волновался: был страх запороть все. Конечно, я в любой момент мог откатиться обратно... но делать этого очень не хотелось.Как же приятно было в итоге увидеть желаемый результат... К слову, я допустил один серьезный промах. Вечером в пятницу закоммитились не все, а т. к. апдейтиться в понедельник не имело смысла (как и следовало ожидать, merge не справлялся), приходилось заново сливать копию (ведь коммититься без апдейта - грех ). Поэтому незакоммиченные изменения тем, кто не закоммитился в пятницу вечером, пришлось вносить вручную. Благо, абсолютное большинство все же закоммитилось в пятницу, поэтому серьезных проблем это не вызвало (а могло бы...).Вот такая дурацкая история. Здесь, конечно, по большому счету виноваты не Guid'ы, а моя кривая библиотека hands.dll... но тем не менее после этого случая к Guid'ам я отношусь с опаской |
| Автор: Idsa 25.3.2009, 23:29 | ||||
Вот хороший анализ Guid'ов в плане производительности: http://www.sql-server-performance.com/articles/per/guid_performance_p1.aspx, http://www.sql-server-performance.com/articles/per/guid_performance_p2.aspx. Если Select выполняется терпимо, то Insert тормозит не по-детски.
В смысле? |
| Автор: jonie 26.3.2009, 00:07 | ||||||
насчет тормозов конкретно в этой задаче несогласен. SQL CE ограничен и очень даже сильно.
в остальном, конечно, да.. но стоит ли данная задача так заморачиваться на скорость - решать автору. репликация доступна начиная с версии стандарт, если не ошибаюсь. |
| Автор: vutsh 26.3.2009, 10:44 |
| Да скорее всего буду делать через гуиды... |
| Автор: PashaPash 26.3.2009, 12:36 | ||||
Только не вручную заюзай репликацию, она сделает через гуиды почти автоматом.jonie, а на нас сейчас кастомер в суд хочет подать и деньги забрать. Типа, софт не соответствует общепринятым стандартам. Придирки: 1. Использование GUID в качестве PK 2. Использование newid() вместо NEWSEQUENTIALID() 3. База не в 4-й NF 4. Использование ORM вместо ручной работы с sql....
А ты попробуй в дизайнере таблиц вбить значение по умолчанию (NEWSEQUENTIALID()) для колонки uniqueidentifier - она ругнется на синтаксическую ошибку, потребует 2 раза подтвердить перед сохранением. |
| Автор: Idsa 27.3.2009, 17:11 | ||||||||
А что вас побудило использовать Guid'ы?
Весьма спорная претензия.
А в чем претензия? Это каким-то образом снизило производительность или ограничило функционал? И, кстати, какая ORM использовалась?
Хех... Действительно Попробовал в Management Studio от 2008-го Sql Server - та же фигня. |
| Автор: PashaPash 27.3.2009, 17:49 | ||||||
Не нас. Моего предшественника ;)
Для сайта с /как выяснилось при сдаче проекта/ с требованием держать 1M транзакций в месяц -> необходимостью кластеризации -> упорядоченность ключа по времени - вполне нормальное требование.
Претензия примерно такая - сам заказчик писали проект на ASP.NET, и там орм тормозил. Поэтому все ормы тормозят. Потому что они выбирают данные из отдеельных таблиц, а не из специально обученных вьюшек...бла-бла-бла..."общепринятые индустриальные стандарты требуют ручной работы с sql, все остальное is evil". И вот докажи что не олень... Юзали NetTiers (кстати, !!!НИКОГДА!!! не используйте NetTiers). |
| Автор: Idsa 27.3.2009, 18:13 | ||||||
Ааа. Вон оно что.
А что это за стандарты такие? Где почитать? ORM - уже мэйнстрим, и это факт.
А тесты, доказывающие обратное, не пробовали проводить? |
| Автор: PashaPash 27.3.2009, 18:32 | ||||
Мейнстрим по какому показателю? По количесву проектов - мейнстрим - это руби и php, без всяких орм. А аргументы в пользу ручной работы с sql всегда найти можно...например приложение будет расти, и придется делать какие-то "ручные оптимизации". А орм не дает полного контроля. А заказчику он воможно понадобится, поэтому "перепишите все заново, без ORM, и бесплатно".
Так заказчик тоже тесты проводить умеет... И к тому же он old school PHP-ник |
| Автор: Idsa 27.3.2009, 21:05 | ||||||||||
Мэйнстрим для свежесоздаваемых проектов.
А в Руби вроде по умолчанию есть какая-та замута на тему ORM...
Да... Тяжела наша доля
Так я из твоих слов понял, что тесты в твоих интересах: мол, на самом деле тормозит вовсе не ORM.
 |
| Автор: PashaPash 28.3.2009, 16:53 | ||
Там ничего не тормозит, просто заказчик такой попался |
| Автор: Partizan 28.3.2009, 19:04 |
| Idsa, PashaPash,  |
| Автор: Idsa 28.3.2009, 21:07 |
Partizan, не ругайся  |