въпрос за REPLACE

ако си решиш проблема със дублирането на инсъртите ще е хубаво

но не бъркай функциите на ПК (primary key) и на индекса! това че в mysql-a ПК е и индекс е друг въпрос. ПК има за цел единствено да ти гарантира уникалността на данните и не смесвай това с функциите на индекса

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

може да се окаже че махайки полето с датата да получиш много по-ефективно търсене отколкото с него. просто тествай!

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

знаеш ли, аз чак сега разбрах какво имаш предвид с това че таблицата не ти харесва. По принцип съм свикнал да се пазя от таблици без PRI. Просто да имам подобна таблица за мен беше недопустимо ! Досега :))
една бърза проба, 150 реда, едната таблица с 4 индекса, по един за всяка колона, и старата с 4-те PRI-та: дори и при толкова малко редове, тази с индексите сканира само 31 реда, докато другата си караше през всички, и щеше да използва индекс при 30 000 записа сигурно.
Датата не мога да я махна, трябва да знам кога са извършени нещата, важно е. А за размерите на файловете не мога да видя, с InnoDB съм.
със сигурност обаче, ще махна PRI-тата, и то не само тук
то не трябва много да се смея, че ако ме усети Пенева ..., учителката ми по бази данни, имам предвид

ихаа, ква караница се заформи :)
жалко, че късно я виждам, ама и аз да тура мерудийка малко ...

та да кажа, че не си прав за keys & indexes, едното е физическа реализация на другото

не разбрах що като не ви харесва думичката primary key не я заместихте с unique key - ключът като такъв изисква минималност, а когато има повече от един ключ, то един от тях посочваме един от тях за primary key и то точно някой от тези, които са минимални и функционално определят всички атрибути (да не навлизаме в теория), т.е. ако има един уникален ключ го наричаме primary key, а ако има няколко - единият (избран по горепосочения начин) е primary, а другите са unique (принципна разлика няма)

вярно е, че ключът е логическата единица, а индекса е физическата - но има ли ключ, има и съответния индекс - иначе няма как да се реализира едното без другото (не визирам случаите като в InnoDB, където ако направиш foreign key, трябва сам да си направиш индексите, щото ауто режима още го няма - поне така беше, не ми се търси в док., за да проверявам)

та гарантирането на уникалността на данните в primary key-а се прави точно с уникален индекс, т.е. не може ли да вкара в него entry, щото има такова - фърля грешка (за справка - oracle, mysql, ms sql, ....)

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

Всички InnoDB таблици са с клъстерен PK така, че по принцип InnoDB таблица без PK няма особен смисъл. И в този ред на мисли ако за MyISAM PRIMARY и UNIQUE са реализирани по един и същ начин при InnoDB разликата е огромна

Май с това трябваше да започнеш

salle.online.bg/sig

за физическата реализация на ПК си прав, бирата ще е от мене май

баси, човека кво питаше, то кво се получи накрая....

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

select uasUserID, count(*) from table group by UserID

+-----------+----------+

| uasUserID | count(*) |

+-----------+----------+

|         1 |      268 |

|         4 |       23 |

|         8 |       54 |

|        16 |        5 |

|        25 |        5 |

|        29 |       16 |

|        55 |       16 |

|       150 |       16 |

|       162 |       21 |

|       192 |       21 |

|       200 |       16 |

|       250 |       16 |

+-----------+----------+

12 rows in set (0.00 sec)



таблицата с Индексите:

explain select * from indx where uasUserID = 8 and uasActionID = 1;

+-------+------+---------------+------+---------+-------+------+------------+

| table | type | possible_keys | key  | key_len | ref   | rows | Extra      |

+-------+------+---------------+------+---------+-------+------+------------+

| indx  | ref  | user,action   | user |       2 | const |   54 | where used |

+-------+------+---------------+------+---------+-------+------+------------+

1 row in set (0.00 sec)



таблицата с PRI:

explain select * from pris where uasUserID = 8 and uasActionID = 1;

+-------+------+---------------+---------+---------+-------+------+-------------------------+

| table | type | possible_keys | key     | key_len | ref   | rows | Extra                   |

+-------+------+---------------+---------+---------+-------+------+-------------------------+

| pris  | ref  | PRIMARY       | PRIMARY |       2 | const |   54 | where used; Using index |

+-------+------+---------------+---------+---------+-------+------+-------------------------+

1 row in set (0.01 sec)



1 000 000 000 e broikata.



таблицата с PRI:

mysql> select benchmark(1000000000, 'select * from pris where uasUserID = 8 and uasActionID = 1');

+-------------------------------------------------------------------------------------+

| benchmark(1000000000, 'select * from pris where uasUserID = 8 and uasActionID = 1') |

+-------------------------------------------------------------------------------------+

|                                                                                   0 |

+-------------------------------------------------------------------------------------+

1 row in set (1 min 17.95 sec)



таблицата с Индексите:

mysql> select benchmark(1000000000, 'select * from indx where uasUserID = 8 and uasActionID = 1');

+-------------------------------------------------------------------------------------+

| benchmark(1000000000, 'select * from indx where uasUserID = 8 and uasActionID = 1') |

+-------------------------------------------------------------------------------------+

|                                                                                   0 |

+-------------------------------------------------------------------------------------+

1 row in set (1 min 25.42 sec)

Тези бенчмаркове май не са много показателни, при няколкото други, и за двете таблици даде почти едно и също време.
например за UserID = 1, където са почти половината от редовете с него, PRI изобщо не използва индекси, а сканира цялата таблица, докато с Индексите си ги използваше

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

сложи си PRI кей нещо леко и частично и ползвай комплексен индекс с това което ти трябва :-)))) (или изобщо не слагай)

примерно ако искаш да гледаш за дата ... сложи си индекса (field1,field2,field3,timestamp(8))

Това ще ти
1.намали индекса като размер
2.ускори търсенето и групирането

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

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

А и в теорията мижеш да срещнеш израза "Индекс върху Първичния Ключ"

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

Казах, че такава таблица с ПК прави теорията много щастлива защото това е една много добре нормализирана таблица.

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


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

Ако pip беше започнал с това, че таблицата е InnoDB обаче нещата ес променят коренно.

InnoDB винаги прави клъстерен индекс независимо дали е дефиниран какъвто и да е индекс или не.

Това определено обезсмисля съществуването на InnoDB таблица без индекси нали?

Та във случая на pip ПК придобива съвсем друг смисъл.
InnoDB ще натъпче всичките му данни в индекса! А това вече означава както по-компактно съдържание така и по-добро бързодействие нали?

salle.online.bg/sig

в такъв момент обикновенно се вика сервитьорката и се поръчва още бира!
Наздраве

Викни една и за мене :-))))
съботно - неделно как сме ?

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

тук сме...
щи звънна да пием бира

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