Общие > Базы данных

Что лучше SET или TINYINT???

(1/3) > >>

qwer3d:
делаю таблицу.
Много полей в которых надо хранить простые числа (1,2,3 и т.д.)

в одном поле одно число.

Будет происходить поиск по этим полям.
Что лучше назначить тип поля set или tinyint?

если будет 50.000 записей то быстрей искаться будет по какому типу?

дело в том что не всегда будут забиты все поля информацией.
tinyint - если нечего не указано то всегда хранит НОЛЬ.
а set - может быть пустым полем.
тут и появляетсья разница в размере базы.
при tinyint --- размер 20 мегов
при set --- размер 8 мегов

с одной стороны set позволяет экономить место на жестком и вроде быстрей должен искать.

ЧТО БЫСТРЕЙ РАБОТАЕТ??? выборка по set или tinyint?

hanslinger:
А ЕСЛИ ПРОВЕРИТЬ СКОРОСТЬ ВЫБОРКИ?????????????????????

qwer3d:
hanslinger

проведу. но вдруг есть официальная инфа по этим типам.

дело в том что если указать везде тип TINYINT ---- то в сам файл базы все будет писаться в одну строчку.
тем самым одна запись - одна строчка - это дает очень быструю скорость (проверял на другом проекте)

а вот если будет тип SET - то я не знаю как Мускул будет писать в сам файл базы.
Если запишет как две строчки:
1. это будет например id (INT)
2.а если он посчитает SET как текстовую то он ее перенесет на вторую строчку в файле

ну и само-сабой если он не посчитает SET как текстовую строчку, то он все запишет в одну строчку тем самым будет очень большая разница в скорости.

Известно точно, что типы BLOB, TEXT, VARCHAR и т.д. --- тоесть которые не имеют постоянной длины --- эти типы мускул записывает в несколько строк НА ОДНУ запись. Тем самым очень сильно падает скорость.

Я не зря задал этот вопрос так как тут уже получаеться на уровне физической записи данных и так же физ. чтения данных.
А это очень важно.

Я по этому форуму лазил и понял что очень многие на самом деле не умеют и не понимают для чего типы данных созданы в мускул.
тем самым допускают ошибки получая большую нагрузку на маленькие базы и т.д.

ravshaniy:
qwer3d
У Вас уже не первый пост по базам данных. все вопросы как раковая опухоль на здоровом теле - аномалия. Вы случаем не тестер? мне интересно к чему ваши исследования базы данных? innoDB myIsam, set - TINYINT, чем можно открыть файлы базы? очень странные вопросы. проясните цель исследований - интересно.

На мой взгляд. Большенство проблем в сложных проектах к коим могут относится проекты связаные с высокой нагрузкой.
Этап проектирования пропущен, уровень абстракции не достаточен. При достаточно быстрой реализации на начальной стадии вы можете получить загубленый в целом проект. Уровень абстракции было бы не плохо начать с проектрирования системы которая не зависила бы от платформы реализации.

если у вас уже есть эта система и вы уже реализуете ее на mysql то боюсь у вас больное место вскрывается. использование нестандартных методов - явный симптом болезни в целом. возможно вам следует пересмотреть сущности вашей системы. и добавить новые уровни абстракции данных которые упростили бы логику работы в целом

извините если не по теме.

ravshaniy:
теперь по теме

--- Код: ---ENUM(\'value1\',\'value2\',...)

An enumeration. A string object that can have
only one value, chosen from the list of
values \'value1\', \'value2\', ..., NULL or the special \'\' error value.
An ENUM column can have a maximum of 65,535 distinct
values. ENUM values are represented internally as integers.

SET(\'value1\',\'value2\',...)

A set. A string object that can have zero or more
values, each of which must be chosen from the list of
values \'value1\', \'value2\', ... A SET column can have a maximum of 64 members. SET values are represented internally as
integers.

TINYINT[(M)] [UNSIGNED] [ZEROFILL]

A very small integer. The signed range is -128 to 127. The
 unsigned range is 0 to 255.


--- Конец кода ---


выбирайте любой приемлемый и масштабируемый тип данных, все они int по сути дела. на мой взгляд на скорости это не отразиться. от себя хотел бы добавить что использование SET и Enum - лучше заменить на нормальные справочники - таблицы с данными. причина достаточная для этого изменения на мой взгляд следующая. если справочники будут меняться, вам не придется делать альтер тейбл, что может привезти к потере данных и не возможности откатиться без серьезных переделок в функционале уровня представления.

Навигация

[0] Главная страница сообщений

[#] Следующая страница

Sitemap 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 
Перейти к полной версии