За последние 24 часа нас посетили 18765 программистов и 1724 робота. Сейчас ищут 1095 программистов ...

Наиболее подходящий тип данных

Тема в разделе "MySQL", создана пользователем Penegan, 17 мар 2010.

  1. Penegan

    Penegan Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    44
    Симпатии:
    0
    Здравствуйте!

    Подскажите какой тип данных наиболее подходящий будет для чисел с 22 знаками?
    Код (Text):
    1. 1234567891234567891234
    Заранее благодарен
     
  2. Apple

    Apple Активный пользователь

    С нами с:
    13 янв 2007
    Сообщения:
    4.984
    Симпатии:
    2
    Операция с числами осуществляется через сторонний скрипт или с помощью SQL-запросов?
    Мне кажется, что это не более, чем какое-то случайное число, с которым не производится никаких математических действий, поэтому самое подходящее - поле CHAR(22) или VARCHAR (при наличии в таблице подобного типа данных).
     
  3. Simpliest

    Simpliest Активный пользователь

    С нами с:
    24 сен 2009
    Сообщения:
    4.511
    Симпатии:
    2
    Адрес:
    Донецк
    Смотря что это за данные.
    Если это числа, с которыми надо проводить математические операции, то посмотреть в сторону DECIMAL

    Если это какой нибудь карточный код или инвентарный номер, то VARCHAR/CHAR
     
  4. Penegan

    Penegan Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    44
    Симпатии:
    0
    это первичный ключ, и по нему будет вестись поиск
    [sql]UPDATE ... WHERE `key` = ...[/sql] и эта операция выполняется при типе VARCHAR 2-6 сек. Думал сократить время, подобрав более подходящий тип, но видать нужно искать что-то другое...
     
  5. Костян

    Костян Активный пользователь

    С нами с:
    12 ноя 2009
    Сообщения:
    1.724
    Симпатии:
    1
    Адрес:
    адуктО
    Penegan
    а индекс стоит?
     
  6. Simpliest

    Simpliest Активный пользователь

    С нами с:
    24 сен 2009
    Сообщения:
    4.511
    Симпатии:
    2
    Адрес:
    Донецк
    сколько полей в таблице? сколько записей в таблице?

    Для UPDATE индексы замедляют работу. Это между прочим.
     
  7. Penegan

    Penegan Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    44
    Симпатии:
    0
    нет, поставил индекс, стало писать, что нужно удалить или первичный ключ или индекс
     
  8. Simpliest

    Simpliest Активный пользователь

    С нами с:
    24 сен 2009
    Сообщения:
    4.511
    Симпатии:
    2
    Адрес:
    Донецк
    Penegan
    чуть больше информации о структуре таблицы и о планируемых запросах.
     
  9. Костян

    Костян Активный пользователь

    С нами с:
    12 ноя 2009
    Сообщения:
    1.724
    Симпатии:
    1
    Адрес:
    адуктО
    Penegan
    удаляй индекс, делай char 22
     
  10. Penegan

    Penegan Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    44
    Симпатии:
    0
    записей до 10млн. 13 полей
     
  11. Костян

    Костян Активный пользователь

    С нами с:
    12 ноя 2009
    Сообщения:
    1.724
    Симпатии:
    1
    Адрес:
    адуктО
    Penegan
    а зачем такие большие числа?
     
  12. Penegan

    Penegan Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    44
    Симпатии:
    0
    суть в следующем:
    нужно добавлять данные в таблицу и при совпадении ключа обновить эту строку


    Код (Text):
    1.  
    2. mysql_query("INSERT INTO table VALUES()");
    3. if (preg_match("/.*Duplicate\sentry.+/i", mysql_error())) {
    4. mysql_query("UPDATE table SET `fld` = ".$fld.", `fld2`='".$fld."' WHERE `key`=".$id." LIMIT 1");
    5. }
     
  13. Simpliest

    Simpliest Активный пользователь

    С нами с:
    24 сен 2009
    Сообщения:
    4.511
    Симпатии:
    2
    Адрес:
    Донецк
    Угум...
    Так ну сейчас прогоним.

    А пока посмотрите в сторону INSERT ON DUPLICATE
     
  14. Penegan

    Penegan Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    44
    Симпатии:
    0
    Ну это уникальное поле, которое генерируется с нескольких остальных той же таблицы, сделано для поиска идентичных полей при вставке

    допустим данные:
    [sql]
    P D E F G L K key
    12556 15 19988 123356 12 48 456 1998812335612
    [/sql]

    key - это соединенные поля E F G и является первичным ключом

    таким образом при вставке строки у которых поля EFG будут такими же, mysql_error() будет писать ошибку Duclicate entry...

    и соответственно обновляем это поле установив обновленные значения, допустим полей P и D.[/sql]
     
  15. Simpliest

    Simpliest Активный пользователь

    С нами с:
    24 сен 2009
    Сообщения:
    4.511
    Симпатии:
    2
    Адрес:
    Донецк
    Penegan
    Ускорить процесс поможет тюнинг сервера БД.
    Плюс если данные нужны все же не все сразу, то партиционирование еще даст прирост в скорости.

    Ну и стандартный master-slave, где запись только на master, а чтения со slave'ов

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

    Костян Активный пользователь

    С нами с:
    12 ноя 2009
    Сообщения:
    1.724
    Симпатии:
    1
    Адрес:
    адуктО
    Penegan
    а, что нельзя уникальный ключ сделать, а праймари оставить обычным автоинкриментным полем. + сделать индекс для поиска по трём плям и всё залетает
     
  17. Simpliest

    Simpliest Активный пользователь

    С нами с:
    24 сен 2009
    Сообщения:
    4.511
    Симпатии:
    2
    Адрес:
    Донецк
    Ты в этом уверен?
     
  18. Костян

    Костян Активный пользователь

    С нами с:
    12 ноя 2009
    Сообщения:
    1.724
    Симпатии:
    1
    Адрес:
    адуктО
    нет;

    ну тогда триггер пусть сделает...
     
  19. Simpliest

    Simpliest Активный пользователь

    С нами с:
    24 сен 2009
    Сообщения:
    4.511
    Симпатии:
    2
    Адрес:
    Донецк
    Прикольно. а он что даст? :)
     
  20. Костян

    Костян Активный пользователь

    С нами с:
    12 ноя 2009
    Сообщения:
    1.724
    Симпатии:
    1
    Адрес:
    адуктО
    он будет сам в ставлять key, это будет быстрей чем вставлять запросом, если на key будет висеть укикальный. Тогда получиться один индекс и уник на кее, но он не будет праймари
     
  21. Penegan

    Penegan Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    44
    Симпатии:
    0
    понято, спасибо, будем пробовать варианты:)

    и еще вопрос, по обычному примари (с типом INT) будет быстрее выполнятся запрос?
     
  22. Penegan

    Penegan Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    44
    Симпатии:
    0
    и еще не будет ли быстрее сначала удалить строку и потом вставить новую, чем обновление полей в той же?
     
  23. Костян

    Костян Активный пользователь

    С нами с:
    12 ноя 2009
    Сообщения:
    1.724
    Симпатии:
    1
    Адрес:
    адуктО
    какому такому обычному и быстрее чем что?
     
  24. Penegan

    Penegan Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    44
    Симпатии:
    0
    перефразирую:)

    будет ли запрос
    [sql]
    UPDATE table SET ... WHERE key = 12345
    [/sql]

    выполнятся быстрее, если тип данных поля key будет не CHAR, а INT?
     
  25. Костян

    Костян Активный пользователь

    С нами с:
    12 ноя 2009
    Сообщения:
    1.724
    Симпатии:
    1
    Адрес:
    адуктО
    Penegan
    теоретически да, но я не уверен, максимум одинаково, только хватит ли тебе диапазона инта для таких чисел