Здравейте,
Първо да побързам да се извиня, ако поставям вече разсикван въпрос, но впечатленията ми от търсачката са, че това не е обсъждано.

Проблемът който ми се стовари на главата преди време бе, че на едно място някъкви хора решили, да използват не светата троица Apache-MySql-Php, а нещо абсолютно безумно като MCMS-MSSQL-ASP (Microsoft Content Managment Server - Microsoft SQL server - ...) и разбира се всичкото това със всичките му (r)-чета, (c)-та и (тм)-ta.
Мъка ми е да си представя, тия люде дето са инсталирали, конфигурирали и администрирали тая система, ама едно е ясно. По някъква безумна причина свише на мен ми се налага (сега доста време от как никой не пипал тая система дори за най проста поддръжка) да я вкарам у релсите та да си кара както си му е ред.
Проблема, както се оказа преди малко е, че никой не е барнал ама грам нищо по тая система от бая време... Някои проблеми бяха преборени, обаче остана точно един
Проклетата база данни е нарастнала до 27 GB, а това напръв поглед изглежда отвратително нелогично.

След камара време загубено в изследване на базата данни единственото подозрение е в преповтарящи се записи с информация като да речем timestamp-а им би могъл да е различен.

Иначе казано имаме клонирани редове от гледна точка на бизнес логиката на приложението, а не в смисъла на базоданновия сървър.

Та... Вече не знам колко опита направих да съчиня нещо с което да мога да изнамеря повтарящите се записи (вероятно се досещате, че става дума за BLOB-ове). GROUP BY им се мръщи, SELECT DISTINCT отказва ди ги обработва... Изобщо почти всички техники които са препоръчителни в такива случаи не ебават (моля да ме извините) да си свършат работата

Е, някой от вас да се е сблъсквал с подобен проблем? Как да изнамерим duplicated rows със BLOB полета..? И не само да ги изнамерим, ама и да ги почистим?

Само да кажа, че тая гнус се поддава само на оператора LIKE, ама и да пукна няма да мога да измисля как да го впрегна, че да ми свърши работа..

ПП. Говорим за MS Transact SQL

Ужас! Тия блобове поне от текстов тип ли са? Ако да - единственото, което ми идва на акъла е да си добавиш нова колона в таблицата, която съдържа дублираните записи. Типа на колоната го направи CHAR с такава дължина, че да може да побира текста от блоба. Предполагам, че 1024 все ще ти стигне. После направи индекс по новата колона. Направи си програмка, която да прехвърли съдържанието от блоба в новата колона. От там нататък, предполагам знаеш какво да правиш...

Успех!

Това чудо Microsoft SQL Server какъв конкурентен контрол има и съответно има ли аналог на вакуумирането в PostgreSQL?

Колкото до двоичните данни, не можеш ли да им направиш на всеки по една md5 сума?

Everything louder than everything else...

+1 за MD5 на BLOB-овете и после distinct по BINARY(16) колона, etc.

Виж тук

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Ако се повтарят И не ти трябват с MD5 ще стане, въпреки че има шанс 1/10 ^ n да не се повтарят, а хеша да е същият.

Ако обаче сървърът ти има навик при промяна на BLOB да раздува файла, най-добре първо пробвай DBCC SHRINKDATABASE
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_dbcc_3pd1.asp

Не знам как го сметна този "шанс" (много е далече от истината, особено като не си казал какво е n), но допълнително може да се проверява и за равество по DATALENGTH примерно.

cheers,
</wqw>

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

Ах, да извинете ме, че не обърнах внимание за типа на полето. Става дума за поле тип image.

Колкото до shrink-ването - то си върви като стандартна задача през няколко дена и човек като се вгледа, открива, че празното място в базата данни не е повече от 10%. Страницирането е наред и изобщо, ако питаш Enterprise Manager-а всичко е така както би трябвало да бъде, че и малко повече.

За md5 - и мен ме притеснява, че това няма да ми даде 100% достоверни резултати.

Има някакви начини да cast-на image към binary, ам апоследното е до 8К пък тия картинки са доста повече.

В таблицата има едно поле дето се нарича BlobSize и вероятно индентифитицира размера на image полето. Едната техника която опитах е да групирам по размера, обаче това отново не ми дава 100% гаранции че няма да затрия нещо дето не трябва, пък и освен друго не съм сигурен до колко е коректна стойността в това поле.

В крайна сметка, вече започвам да си мисля, че всъщност базата няма проблем а наистина информацията (полезната) в нея си е точно толкова...

Но това, разбира се, е само оправдание :)

О, благодаря - мисля, че това би могло да се приложи!
Ще опитам!