|
|
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Такая оказия… Вот запрос: Код: sql 1. 2. 3. Это повторяющаяся часть запроса, вырезанная из цикла. Здесь в таблицу заносится массив слов с пропуском уже существующих. Но заметил, что эта зараза слова-то пропускает, а вот первичный ключ повышает всё равно и получаются большие дырки в первичном ключе: занёс слов сто, а показывает номер последнего слова аж за 800… Как сделать так, чтобы пропуская уже существующее в таблице слово, первичный ключ не накручивался, а повышался только при записи именно нового слова? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 05:29:50 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
это тебя не должно волновать. значений первичного ключа тебе хватит с бльшим запасом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 06:42:29 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
+а если нужна своя нумерация, то надо завести своё поле для своей нумерации, т.к. нумерация не есть назначение ПК. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 08:42:45 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Но вы так и не ответили, на это можно повлиять или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 12:36:31 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkНо вы так и не ответили, на это можно повлиять или нет?Нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 12:38:07 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Точнее, можно, но ухудшив производительность. Схема такая: 1) Блокируете таблицу 2) SELECT-ом проверяете наличие нужной записи 3) Если нет, то INSERT 4) Снимаете блокировку Это приведет к ухудшению быстродействия как отдельных вставок, так и в массе из разных сессий (они будут выполняться последовательно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 12:41:05 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Просто получается очень огромные дырки будут, т. к. в бд постоянно будут попытки занести дубликат. И среди этих попыток, если появится слово новое, то у него будет уже огроменный индекс. Может тогда лучше переписать запрос, чтобы проверялось сначала наличие , а потом только вставлялось? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 14:03:03 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkу него будет уже огроменный индексНу и что? Это вещь сугубо технологическая, не стоит о ней беспокоиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 14:10:59 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
On 31.07.2014 06:29, andrejk wrote: > заносится массив слов с пропуском уже существующих. Но заметил, что эта > зараза слова-то пропускает, а вот первичный ключ повышает всё равно и > получаются большие дырки в первичном ключе: занёс слов сто, а показывает > номер последнего слова аж за 800… Ну и фиг с ним, тебе -то что ? > Как сделать так, чтобы пропуская уже существующее в таблице слово, > первичный ключ не накручивался, а повышался только при записи именно > нового слова? Зачем -- вот главный вопрос. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 15:05:19 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
On 31.07.2014 06:29, andrejk wrote: > mysql_query(" > INSERT IGNORE INTO `ts`(`s`) > VALUES ('" . $massiv_itog[$i] . "')"); > Как сделать так, чтобы пропуская уже существующее в таблице слово, > первичный ключ не накручивался, а повышался только при записи именно > нового слова? Дай ПОЛНОСТЬЮ нормальный SQL-запрос, который ты выполняешь, а я тебе может быть скажу, как свести к минимуму этот эффект. Т.е. может дырки и будут, но не такие огромные. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 15:07:21 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkПросто получается очень огромные дырки будут, т. к. в бд постоянно будут попытки занести дубликат. И среди этих попыток, если появится слово новое, то у него будет уже огроменный индекс. Может тогда лучше переписать запрос, чтобы проверялось сначала наличие , а потом только вставлялось? Конечно, может. select name from tbl_newvalue where name not in (select name from tbl_oldvalue) Соответственно, отберутся только те записи, которых еще нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 15:22:16 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
UsersКонечно, может. select name from tbl_newvalue where name not in (select name from tbl_oldvalue) Соответственно, отберутся только те записи, которых еще нет.Можно и так, но IN (SELECT ...) лучше переписать через JOIN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 15:33:26 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
MasterZivOn 31.07.2014 06:29, andrejk wrote: > заносится массив слов с пропуском уже существующих. Но заметил, что эта > зараза слова-то пропускает, а вот первичный ключ повышает всё равно и > получаются большие дырки в первичном ключе: занёс слов сто, а показывает > номер последнего слова аж за 800… Ну и фиг с ним, тебе -то что ? А то. MasterZiv> Как сделать так, чтобы пропуская уже существующее в таблице слово, > первичный ключ не накручивался, а повышался только при записи именно > нового слова? Зачем -- вот главный вопрос. Нада. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 16:09:25 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Вот этот запрос в коде ПХП. Получается, что ПК не данные считает, а колличество обращений к БД. Это у меня вызывает когнитивный диссонанс и становится неудобно жить ;-). Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 16:15:21 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Решил проблему через дополнительный проверочный запрос. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 18:57:32 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkВот этот запрос в коде ПХП. Получается, что ПК не данные считает, а колличество обращений к БД. Это у меня вызывает когнитивный диссонанс и становится неудобно житьОсознайте, что ПК не должен "считать" ни "данные", ни "количество обращений к БД", что это просто ссылка на запись, и "диссонанс" исчезнет. Хотите считать количество строк или запросов, делайте соответствующие счётчики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2014, 20:55:37 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Ребята, не надо в моих словах искать глупость, я понимаю, что такое пк, но я не вижу смысла делать какие-то счётчики, если это можно сделать с помощью пк. Где ваше чувство рационального? Меня просто убивал тот факт, что пк реагирует на все шорохи и всё. По-моему, это было через жопу, просто так совпало, что это принцпиально не вредит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 01:36:28 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkне надо в моих словах искать глупостьдействительно, зачем её искать, если её сразу видно? andrejkМеня просто убивал тот факт, что пк реагирует на все шорохи и всё. По-моему, это было через жопуЧитать 5755138 , долго и вдумчиво. Потом поразмыслить над следующей ситуацией: есть таблица trololo (id int autoinc, val int) выполняем (именно в таком порядке) session1: begin session2: begin session1: insert into trololo (val) values (1) session2: insert into trololo (val) values (2) session1: rollback session2: commit и после этого думаем, как именно сервер должен извращаться, чтобы обеспечить отсутствие дыр. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 07:47:33 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Меня зацепил не факт наличия дыр, а причина их появления. В моём случае дыры будут тоже, если введённое слово, например «х.й», потом удалить (а таких слов будет куча: фвафывафы, 24352452, 7777777777, рорррррррррр…, — пока не набалуются). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 12:48:00 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkдыры будут тоже, если введённое слово потом удалитьв чём вы видите принципиальную разницу между моим примером и вашим? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 14:32:50 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
tanglirandrejkдыры будут тоже, если введённое слово потом удалитьв чём вы видите принципиальную разницу между моим примером и вашим? :) А где ваш пример?) Подозреваю, что это: session1: begin session2: begin session1: insert into trololo (val) values (1) session2: insert into trololo (val) values (2) session1: rollback session2: commit Ну так я ещё слово begin не расшифровал, а остальное в общих чертах понял. Вы бы не могли эту последовательность перевести на нормальный язык или прокомментировать строчки? session1: — это один запрос к БД? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 15:33:44 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkА где ваш пример?) Подозреваю, что это: session1: begin session2: begin session1: insert into trololo (val) values (1) session2: insert into trololo (val) values (2) session1: rollback session2: commit Ну так я ещё слово begin не расшифровал, а остальное в общих чертах понял. Вы бы не могли эту последовательность перевести на нормальный язык или прокомментировать строчки? session1: — это один запрос к БД?Ну это даже я понял :) session1 и session2 - обозначение того, в какой MySQL-сессии выполняется запрос Далее, собственно, сам запрос. Слово begin начинает транзакцию. Полезно в тех случаях, когда включен автокоммит. После слова begin автокоммит в этой сессии выключается до завершения транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 15:38:18 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
session1: begin — начал пользователь 1 session2: begin — начал пользователь 2 session1: insert into trololo (val) values (1) — запрос пользователя 1 session2: insert into trololo (val) values (2) — запрос пользователя 2 session1: rollback — пользователь 1 отменил транзакцию session2: commit — а пользователь 2 подтвердил Я правильно понял? И, я так понимаю, сдесь речь идёт об одной общей таблице для всех пользователей, но у меня для каждого пользователя создаётся своя таблица. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 15:58:16 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
tanglirandrejkдыры будут тоже, если введённое слово потом удалитьв чём вы видите принципиальную разницу между моим примером и вашим? :) Да нет, я просто сначала вообще не понял, что вы мне написали))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 15:58:52 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkно у меня для каждого пользователя создаётся своя таблица 13044537 всё, я пас если кому-то интересно, убеждайте его сами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 16:00:47 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Да я ничего и не отстаиваю, я просто пытаюсь понять, что мне написали. Я ещё на том уровне, где лучше словами писать, а не «session — begin». Мне и самому смешно уже, но только от того, что всё в какое-то недоразумение заходит. Короче, выше я привёл своё решение через дополнительнй проверочный запрос — имеет оно право на жизнь? Лучше можно сделать? Вот и всё… ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 16:23:11 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkКороче, выше я привёл своё решение через дополнительнй проверочный запрос — имеет оно право на жизнь? Лучше можно сделать? Вот и всё…Вариант лучше уже был выше - 16382506 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2014, 16:39:02 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkРешил проблему через дополнительный проверочный запрос. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. надо делать не insert... values а insert ... select ... where not exists ( select... where запись с этим ключем ) третье уже в теме намекали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.08.2014, 14:14:44 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Ту т получается риск сбоя, если одно и то же отсутствующее слово будет проверяться одновременно двумя пользователями. Я не знаю суть действия БД Мускуль, поэтому хочу спросить: если переписать всё это в один запрос, то вероятность сбоя останется или нет? И помогите, пожалуйста, составить запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 04:40:45 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejk, insert ignore ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 05:25:33 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
tanglirandrejk, insert ignore Короче, с чего начал, к тому и пришёл? ТОлько через игнорирование? И иначе никак? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 06:18:30 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejk, ну а как вы себе это представляете? можно, конечно, использовать lock table, но тогда зачем вам вообще мускль, пишите сразу на foxpro 2.0 :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 06:22:16 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
tanglirandrejk, ну а как вы себе это представляете? можно, конечно, использовать lock table, но тогда зачем вам вообще мускль, пишите сразу на foxpro 2.0 :) что вы имеете ввиду? я не знаю, чем foxpro 2.0 отличается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 06:37:45 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Но ведь повышение пк из-за каждого запроса это же расход пк вхолостую. Или дойдя до своего предела, он начнёт незанятые словами пк занимать по второму кругу? Если так, то тогда нормально, слов не добавиться больше, чем int. Можете эту тонкость пояснить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 06:52:52 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkИли дойдя до своего предела, он начнёт незанятые словами пк занимать по второму кругу? 2634217 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 07:32:38 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejkНо ведь повышение пк из-за каждого запроса это же расход пк вхолостую. Или дойдя до своего предела, он начнёт незанятые словами пк занимать по второму кругу? Если так, то тогда нормально, слов не добавиться больше, чем int. Можете эту тонкость пояснить? Значит, меньше слушайте спецов по переменным, а больше - спецов по sql. Я вам, тем более, уже писал, как именно надо составить запрос. Допустим, tbl_ts - таблица, куда мне надо вставить данные, при этом проверив, что таких id в ней нет. ts_new - таблица, в которой новые данные лежат. Код: sql 1. 2. Всё. Один запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 09:42:19 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Я прошу прощения, но как ваш вариант прикрутить к моей задаче, у меня, ведь, нет никаких других таблиц, только одна, в которую постоянно вставляют слова пользователи? У меня не с чем сравнивать id. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 13:36:37 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejk, Надо просто подумать. It's easy. Ну, нет id - ничего страшного. Слова-то есть? Код: sql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 13:39:59 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Но слова-то пользователи сами пишут, откуда их select делать? insert tbl_ts(word) — пытаемся вставить слово от пользователя в таблицу, это понятно… select tn.word from tbl_ts_new tn — а это не понятно, откуда мы берём слово?… Сто из моего примера выступает в роли tbl_ts_new? where tn.word not in (select word from tbl_ts); — …, всё, заглох… Пожалуйста, перепешите мой изврат Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. используя мои названия. Мне так легче понять будет логику. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 13:58:57 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejk Код: sql 1. Не буду переписывать. Я вообще не сторонник давать рыбу нахаляву, а удочку я вам дал. Слова у вас лежат в massiv_itog - думайте, как этот массив целиком подствить вместо tbl_ts_new. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 14:15:36 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
А слона-то мы и не заметили))) Я б не догадался массив, как новую таблицу рассмотреть… По крайней мене до пенсии) Так, я понял логику: вставить в таблицу из массива только те слова, которые получатся, если выбрать из массива только те слова, которых в этой таблице нет. Если дословно… Правильно? Но, блин, я, видимо, не вижу очередного слона — как массив прикрутить к запросу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 14:33:31 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejk, открой для себя хранимые процедуры если боишься переполнения bigint но это изврат ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 14:57:52 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Usersandrejk Код: sql 1. Не буду переписывать. Я вообще не сторонник давать рыбу нахаляву, а удочку я вам дал. Слова у вас лежат в massiv_itog - думайте, как этот массив целиком подствить вместо tbl_ts_new. Так, что ли? Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 15:10:24 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
вадяandrejk, открой для себя хранимые процедуры если боишься переполнения bigint но это изврат Как вы они мне помогут, чтоб я знал, с какой стороны их открывать для экономии времени? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 15:11:58 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
andrejk, не так. Код: sql 1. 2. 3. 4. tn - это название выборки, что следует вот из этого: from (SELECT `s` FROM `ts` WHERE `s` = '".$massiv_itog[$i]."') tn тогда выходит следующий запрос: select tn from tn - это вернет ошибку. Поля tn у вас нет. Далее потом: WHERE `s` = - в случае массива надо менять на Where S in Далее еще более потом: where tn not in - это вернет ошибку. Поля tn у вас нет. когда я пишу Код: sql 1. - там tn является алисом таблицы. Алиас помогает написать запрос короче и гибче его менять. Если бы алиса не было, такая запись выглядела бы так: Код: sql 1. Все, это последняя моя запись в этой теме. Что и как делать - понятно, осталось только подумать, этого за вас никто не сделает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 16:15:38 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
UsersВсе, это последняя моя запись в этой теме. Что и как делать - понятно, осталось только подумать, этого за вас никто не сделает. Подумать — это хорошо, когда есть чем оперировать, например знанием забытых особенностей и возможностей синтаксиса. Мне оперировать нечем, я вообще не программист и не студент, я делаю себе маленький инструмент в виде сайта и познакомился пока только с эллементарным синтаксисом. Я начал с нуля недели три назад: PHP + MySQL. Можно, конечно, потратить два года на изучение всех тонкостей, только мне нужно сейчас и не все тонкости, а пока только те, что необходимы. Вот сейчас я не знаю как обращаться с массивами в запросах, я вообще не знаю как это называется, чтобы поискать в интернете, а вы мне пишете отрывки синтаксиса, буд-то мне его вспомнить только осталось. Я сейчас только прикоснулся ко всему этому, я обращаю внимание даже на регистр в том, что вы мне пишете — сложновато получается, когда все пишут по-разному. Спасибо, конечно, за ответ, но помощь почему-то превращается в воспитание. Почему все думают, что человек, который просит пару строчек кода, обязательно ищет халяву? Я учусь по вашему коду, как если бы учился по другому коду в другом месте, в книгах и т. д. Как учиться не читая чужие коды? Если сократить всё «уравнение», то получается, что всё выглядит так: мы тебе ничего не напишем, ищи сам, где уже написали. И в чём разница? И так и так буду по написанному кем-то коду учиться. Я не знаю особенностей синтаксиса, но по примеру могу переделать под свою задачу. Я понял логику вашего примера, я знаю, что tn это псевдоним, но мне не понятно, как там массив учесть… Подозреваю, что надо что-то дописать к tn, но что? Где почитать про то, как совместить запрос с массивом, как вообще это называется? Это хоть можете подсказать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 16:52:24 |
|
||
|
Пропуски в первичном ключе при IGNORE.
|
|||
|---|---|---|---|
|
#18+
Короче, сделал эксперимент — добавил вручную максимальное значение ПК и потом добавил ещё одну запись. БД стала занимать пустые места сначала отсчёта, так что нахрен все эти танцы с бубном, буду через IGNORE добавлять. Вопрос решён, тема закрыта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2014, 23:05:06 |
|
||
|
|

start [/forum/topic.php?all=1&fid=47&tid=1834402]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
77ms |
get tp. blocked users: |
1ms |
| others: | 242ms |
| total: | 405ms |

| 0 / 0 |
