Оптимизированные типы данных + простой дизайн базы данных

Question

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

USERS TABLE
UID              |int               | PK NN UN AI 
username         |varchar(45)       | UQ INDEX 
password         |varchar(100)      | 100 varchar for $6$rounds=5000$ crypt php sha512
name             |varchar(100)      | 45 for first name 45 for last 10 for spaces
gender           |bit               | UN ,0 for women 1 for men, lol.
phone            |varchar(30)       | see [2] 
email            |varchar(255)      | see RFC 5322 [1]
verified         |tinyint           | UN INDEX 
timezone         |tinyint           | -128 to 127 just engough for +7 -7 or -11 +11 UTC
timeregister     |int               | 31052010112030 for 31-05-2010 11:20:30 
timeactive       |int               | 01062010110020 for 1-06-2010 11:00:20

COMPANY TABLE
CID              |int               | PK NN UN AI
name             |varchar(45)       |
address          |varchar(100)      | not quite sure about 100.
email            |varchar(255)      | see users.email, this is for the offcial email
phone            |varchar(30)       | see users.phone
link             |varchar(255)      | for www.website.com/companylink 255 is good.
imagelogo        |varchar(255)      | for the retrieving image logo & storing 
imagelogosmall   |varchar(255)      | not quite good nameing huh? let see the comments
yahoo            |varchar(100)      | dont know
linkin           |varchar(100)      | dont know
twitter          |varchar(100)      | twitter have 100 max username? is that true?
description      |TEXT              | or varchar[30000] for company descriptions
shoutout         |varchar(140)      | status that companies can have.
verified         |tinyint           | UN INDEX 

PRODUCT TABLE
PID              |int               | PK NN UN AI
CID              |int               | from who?santa? FK: company.cid cascade delete
name             |varchar(100)      | longest productname maybe hahaha.
description      |TEXT              | still confused useing varchar[30000]
imagelarge       |varchar(255)      | for the retrieving product image & storing 
imagesmall       |varchar(255)      | for the retrieving small product image & storing 
tag              |varchar(45)       | for tagging like stackoverflow ( index )
price            |decimal(11,2)     | thats in Zimbabwe dollar.

1. см. Использование регулярного выражения для проверки адреса электронной почты
2. см. Какой самый длинный телефонный номер в мире, который я должен учитывать в SQLvarchar (длина) для телефона

Почему именно innodb?см. цитату Как выбрать оптимизированные типы данных для столбцов [характерно для innodb]?

В нем обсуждается тема, поэтому мне нужно создать еще один вопрос, и люди не поймут, что я пытаюсь сказать,или, может быть, я не могу объяснить, чего я хочу там.на этот раз это + дизайн базы данных.

так что, пожалуйста, скопируйте приведенный выше пример и добавьте свои изменения + комментарии точно так же, как пример .дайте совет по этому поводу.

Запомните для INNODB mysql.прочитайте цитату по ссылке выше.спасибо.

Answer 1

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

• Не храните даты и время как целые числа.Вместо этого используйте столбец DATETIME.
• Имейте в виду, что MySQL хранит DATETIME как GMT, но представляет их в любом часовом поясе, для которого он настроен.Возможно, стоит установить часовой пояс для соединения на GMT, чтобы сработало ваше отдельное хранилище часовых поясов.
• Имейте в виду, что не все часовые пояса имеют полные часовые смещения от GMT.Переход на летнее время также может привести к обезьяньему рывку в часовых расчетах.Вы можете сохранить строку часового пояса (например, «America / Los_Angeles») и выяснить правильное смещение во время выполнения.
• Вам не нужно указывать количество символов для целочисленных столбцов.
• Не бойтесь столбцов TEXT.У вас есть много VARCHAR (255) для данных, которые легко могут быть длиннее 255 символов, например URL.

Имейте в виду, что выполняется оптимизация для конкретного механизма базы данных или оптимизация для хранения вдиск это самое последнее, что вы должны сделать.Сделайте, чтобы ваши определения столбцов соответствовали данным .Преждевременная оптимизация - один из многих корней всего зла в этом мире.Не беспокойтесь о tinyint против smallint против int против bigint, или char против varchar против текста против bigtext.Это не будет иметь значения для вас 95% времени, пока данные соответствуют.

Answer 2

Для чего бы то ни было, целочисленный аргумент (например, INT(11)) не имеет никакого значения для хранения или оптимизации в любом случае.Аргумент не указывает максимальную длину или максимальный диапазон значений, это только подсказка для отображения.Это сбивает с толку многих пользователей MySQL, возможно, потому что они привыкли к CHAR(11), указывающему максимальную длину.Не так с целыми числами.TINYINT(1) и TINYINT(11) и TINYINT(255) хранятся идентично как 8-разрядное целое число и имеют одинаковый диапазон значений.

Максимальная длина адреса электронной почты составляет 320 символов.64 для локальной части, 1 для @ и 255. для домена.

Я не фанат использования VARCHAR(255) в качестве объявления строки по умолчанию.Почему 255 правильной длины?Разве 254 не достаточно длинны, а 256 - слишком много?Ответ заключается в том, что люди считают, что длина каждой строки хранится где-то, и, ограничивая длину 255, они могут гарантировать, что длина занимает всего 1 байт.Они «оптимизировали», позволив использовать максимально длинную строку, сохраняя длину до 1 байта.

На самом деле длина поля , а не , хранится в InnoDB. смещение каждого поля в строке сохраняется (см. MySQL Internals InnoDB ).Если общая длина строки составляет 255 или менее, смещения используют 1 байт.Если общая длина строки может быть больше 255, смещения используют 2 байта.Поскольку у вас в строке несколько длинных полей, почти наверняка смещения в любом случае будут храниться в двух байтах.Вездесущее значение 255 может быть оптимизировано для некоторой другой реализации СУБД, но не для InnoDB.

Кроме того, MySQL в некоторых случаях преобразует строки в формат фиксированной длины, дополняя поля переменной длины по мере необходимости.Например, при копировании строк в буфер сортировки, или сохранении в таблице MEMORY, или подготовке буфера для набора результатов, он должен распределять память на основе максимальной длины столбцов, а не длины используемых данных наоснова.Поэтому, если вы объявляете столбцы VARCHAR намного дольше, чем когда-либо фактически используете, вы тратите впустую память в этих случаях.

Это указывает на опасность попытки слишком тонкой оптимизации для конкретного формата хранения.

Answer 3

Вы должны хранить все свои даты / время в GMT. Рекомендуется преобразовать их в смещение 0, а затем преобразовать их обратно в любое смещение местного часового пояса, в котором в данный момент находится пользователь для отображения.

Максимальная длина URL в Internet Explorer (наименьший общий знаменатель) составляет 2000 символов (просто используйте TEXT).

Вы не устанавливаете длины для INT типов (снимите их!). INT - 32 бита (от -2147483648 до 2147483647), BIGINT - 64 бита, TINYINT - 8 бит.

Для bool / flags вы можете использовать BIT, который равен 1 или 0 (ваш "проверенный", например)

VARCHAR(255) может быть слишком маленьким для «imagelarge» и «imagesmall», если оно включает имя и путь к файлу изображения (максимальную длину URL см. Выше).

Если вы не уверены, насколько велика VARCHAR, слишком велика и когда начинать использовать TEXT, просто используйте TEXT!

• 10,2. Числовые типы

Answer 4

USERS TABLE
UID              |int(11)           | PK as primery key ? NN as not null ? UN AI 
username         |varchar(45)       | UQ 
password         |varchar(200)      | 200 is better.
name             |varchar(100)      | ok
gender           |blob              | f and M
phone            |varchar(30)       | 
email            |varchar(300)      | thats 256 , put 300 insted
verified         |tinyint(1)        | UN
timezone(delate) |datetime          | this should be a php job
timeregister     |datetime          | 
timeactive       |datetime          | 

COMPANY TABLE
CID              |int(11)           | PK NN UN AI
name             |varchar(45)       |
address          |varchar(100)      | 100 is fine
email            |varchar(255)      |
phone            |varchar(30)       | 
link             |varchar(255)      |
imagelogo        |varchar(255)      | 
imagelogosmall   |varchar(255)      | the nameing is just fine for me 
yahoo            |varchar(100)      | see 3.
linkin           |varchar(100)      | linkin use real names, maybe 100 is great
twitter          |varchar(20)       | its 20 ( maybe 15 )
description      |TEXT              | 
shoutout         |varchar(140)      | seems ok.
verified         |tinyint(1)        | UN

PRODUCT TABLE
PID              |int(11)           | PK NN UN AI
CID              |int(11)           | FK: company.cid cascade delete & update
name             |varchar(100)      | 
description      |TEXT              | 
imagelarge       |varchar(255)      | 
imagesmall       |varchar(255)      | 
tag              |varchar(45)       | 
price            |decimal(11,2)     | 

в php см. Php.net/manual/en/function.date-default-timezone-set.php

$time = date_default_timezone_set('Region/Town');
$time = date( 'Y-m-d H:i:s' );
echo $time;

3. http://www.eph.co.uk/resources/email-address-length-faq/