въпрос за REPLACE

здравейте,
имам една таблица с 4 колони в която ще има много и чест Insert на данни. с един SQL ще се слагат по няколко реда, т.е. Insert into table values (...), ..., (...);
оказа се обаче че в стойностите които ще се слагат е възможно да има повтарящи се стойности за PRI key-а. така че данните ще се слагат с REPLACE into ...
За да изчистя тези повтарящи се стойности преди да генерирам SQL-а, трябва да се въртят доста цикли в програмата, PRI key-а е и от 4-те колони, като едната е текущото време.

Въпросът ми е, доколко по-бавен е REPLACE от INSERT за подобни чести и масови въвеждания на данни (редовете в таблицата може да станат около 1-2 милиона по някое време), и дали ще е по-ефикасно да ги чистя от scriptа, и след това да си използвам INSERT.
благодаря
:))

много кофти си построил базата
тоя primary key дет си го направил хич не е primary
пък и да включваш вътре текущото време е направо извън пътя
вземи малко ги пооправи тия неща и проблема ти ще се реши

ее, ама много сте бързи с критиката :))
ще обясня малко по-подробно за какво е таблицата, ако и тогава кажете че е зле конструирана, ще преразгледам въпроса.

UserID smallint unsigned PRI
AreaID tinyint unsigned PRI
ActionID tinyint unsigned PRI
Time datetime PRI

AreaID е ID-то на областа на дейстивие, ActionID е ID-то на самото действие.

с тази таблица ще знам Кой, Къде, Кое, Кога е извършил.
т.е. тя е статистическа таблица, в нея ще има Много Insert на данни, но почти никакъв Select.

Ако ми кажете че този PRI кей не е какъвто трябва да е, т.е. ако мога да определя тези неща с тази таблица, като махна някоя колона да не е от PRI-тата, отивам да паля огън за пепел :)
поздрави

Остави го охлюва - сигурно не си е изпил кафето още.


REPLACE всъщност предствлява DELETE + INSERT

Мисля, че това отговаря напълно на въпроса ти.

За твоята конкретна таблица обаче има обаче още по-елегантен вариант.

INSERT IGNORE INTO ...;

IGNORE означава ако има грешка (дублиран ключ) да продължи нататък без пазарлъци.

Както сигурно вече си забелязял когато вмъкваш по много редове наведнъж и някой от тях се повтаря заявката спира дотам - и нямаш начин да разбереш кой точно редове са минали и кои не. IGNORE моменталон ти решава проблема.


За твоя случай няма никакъв проблем понеже ПК обхваща целия ред.
Което между другото на теория е перфектна таблица та и аз не схващам какво не му харесма на охлюва

salle.online.bg/sig

Здравей,
Както винаги си прав.
Принципно знам за Insert IGNORE, че има, само че не знам защо не се сетих за него сам.

според мен Time е времето на действието, нали?

ако е така на мен ми се вижда не възможно да получиш дублиране по primary key

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

и кво му е добрето на тоя key ако не е тайна???

не е въпроса дали на теория е перфектно а има ли изобщо смисъл да го правиш така....

Съвсем правилно е предположението ти.
в процеса на разработката се получи така, че с едно и също извикване на script, може да се изпълние Едно и Също действие в рамките на това извикване. Например имаш 2 части на страницата където данните за тях се различават, но се взимат от едно и също действие с различни параметри към него.
И тогава се получава това дублиране, тъй като в рамките на извикването на scriptа действието се извиква 2 пъти, с различни параметри към него, Ho тогава времето на извикване на действиеTo съвпада и при двете извиквания. И за това така се получава.

I az imam podobna tablica za logwane na eventite, ama ne sam turl PRI KEY, shtoto ne wijdam za kakwo mi e...i q zachistwam, na 6 meseca delwam logs sas data tam < ... etc.

shto ne polzwash MICROTIME ili TIMESTAMP nesto ili prosto dobawish oshte nesto deto unikalizira iztochnika, moje da e MD5(RemoteIP . date(). microtime)...prosto predlagam :>

ами точно така, няма никкъв смисъл от primary key-a!

особенно при положение че скипта който пълни базата позволява да влязат няколко еднакви записа. primary key-a ще си гърми на поразия - той ТОЧНО ТОВА ТРЯБВА да прави в крайна сметка. ако трябва да могат да влизат еднаквите записи, очевидно primary key-a трябва да е друг или пък тъпия скрипт да спре да генерира еднакви записи...

?

salle.online.bg/sig

Една много проста ситуация:

Имаш скрипт който генерира да речем 100 реда в секунда.
От тях 90 се повтарят в таблицата.

Е ако имаш PK таблицата ти ще расте с 10 реда в секунда т.е. 10 пъти по-бавно.

Я сметни колко прави това за един ден?


Амче нали точно това му е смисъла на понятието Пърмичен Ключ - Да не съхраняваш ИЗЛИШНА информация.

salle.online.bg/sig

когато правиш лог няма излишна информация
като не ти трябва просто не я генерирай и не я тъпчи в базата....

Първото е, че по твоята логика изобщо няма смисъл от Първични ключове

Второто е, че ако ти не виждаш смисъл от нещо това не значи, че някой друг не може да види смисъл в него.


"като не ти трябва просто не я генерирай и не я тъпчи в базата...."

Страшно готина идея. И как предлагаш да се реализира, че нещо не схващам?

Всяко нещо дето го генерираш преди това да го проверяваш дали вече не е в БД? Т.е. да преди всеки INSERT oа правиш SELECT? Ето това вече би било глупаво.

Или пък да си пазиш информация в клиентската част за това какво вече е вмъкнато и да не го повтаряш? Ами тогава да те питам за какво ти е База Данни изобщо?

salle.online.bg/sig

ей тва само не разбрах от де го измисли:

"Което между другото на теория е перфектна таблица та и аз не схващам какво не му харесма на охлюва "

какво му е перфектното primary key-a да е целия ред?!?

"Първото е, че по твоята логика изобщо няма смисъл от Първични ключове " - това незнам къде съм го казал...

ти изобщо прочете ли от къде въобще му тръгва проблема на човека:

"Съвсем правилно е предположението ти.
в процеса на разработката се получи така, че с едно и също извикване на script, може да се изпълние Едно и Също действие в рамките на това извикване. Например имаш 2 части на страницата където данните за тях се различават, но се взимат от едно и също действие с различни параметри към него.
И тогава се получава това дублиране, тъй като в рамките на извикването на scriptа действието се извиква 2 пъти, с различни параметри към него, Ho тогава времето на извикване на действиеTo съвпада и при двете извиквания. И за това така се получава."

Я и двамата да ме почерпите по бира и спора ще се реши :-))))

Цялата идея на момъка и на мене не ми е съвесем ясна - т.е. ясна ми е ама реализацията е под всякаква критика ако е това което съм разбрал ...

Ако иска да логва ВСЯКА операция, да я логва. Ако иска да логва само типове операции тогава тиместамп-а не му трябва в първичния ключ. Т.е. за какво повтаря в лог-а една и съща операция в едно и също време ??? След като не му трябва това тогава и операции в интервал 1 секунда по същата логика не му трябват нали.

Цялата постановка не е много чиста, така че по мое лично мнение (не ангажирам никого с него), по-добре е да се изчисти концепцията за това какво, къде и кога трябва да се логва и тогава да се направи лог-инга, така че хем да не натоварва сървърчето, хем да съдържа всичката необходима информация :-)))

П.С. Имам идея за бира пак ама не знам кога ще стане .... първо трябва да ГИ изберем и после ....

Е тук нищо няма:[линк]

иии, браво рошав! явно не съм само аз тоя дето нещо не го кефи в цялата тая работа:)))

айде избирайте ги, ама да не лъжете многу:))
пък като свършите ще го полеем

леле, каква дискусия се развила тук.
Какъв смисъл виждам аз в това което съм направил?

Системата която пиша е доста комплексна. Разделена е виртуално на Области, като всяка област има Действия.
Няколко примера за такива области:
Новини, Форум за анонимни потребители, Форум за Регистрирани потребители.
Действия: Добавяне на новина, Триене на Пост във форум, Update на Пост във форум, etc ...

Действието в scriptа за който споменах е: Вземане на кратко описание на новини. Има 2 вида новини: текущи и архив.
та в scriptа се извиква 2 пъти това действие, един път за текущите, втория път за архива. За това се получава повтарянето на лога.

Системата все още е във фаза на разработка. Това повтаряне на лога няма да го има в бъдеще, защото гореспоменатото действие ще се раздели на 2 действия: вземане на текущи новини, вземане на архивни новини. Т.е. ще има една функция от по-ниско ниво, която ще взема информация за двата вида новини, но самите Действия ще и подават параметри, а не scriptовете към действията. Така повтарянето в лога ще се Елиминира, но За момента го има.

Защо таблицата има такъв PRI key ?
Ами защото както се вижда, за 1 седмица тази таблица може да стане от порядъка на 5 милиона реда преди да се архивира информацията.
Вижда се също така, че там се записва Всяко едно действие. Еми чрез тази таблица аз мога да проследя напълно и Едноцначно Всеки потребител къде, какво, кога е правил, и то в рамките за конкретната му сесия !
Но при 5 милиона реда едно
'WHERE UserID = x AND AreaID = y GROUP BY ...', представете си колко време ще отнеме ако няма PRI кей. Но ако го има, тези условия UserID = x AND AreaID = y, значително ще намалят това време. Ако задам и едно 'Time > "хххх-xx-xx" AND Time < "хххх-xx-xx"', смятайте още колко по-бързо ще стане работата. Ако няма PRI кей, ще си седя цял ден да чакам за резултати.
А нали все пак една статистика се води, за да се Анализира ! И то Своевременно.

Поздрави на всички и благодаря за мненията