Есть таблица в крайне упрощенном варианте в ней есть поле var типа c названием COLOR, в ней цвета: белый, красный....черный
либо, (по правилам нормализации БД)
Есть таблица в ней поле COLOR int типа + вторая таблица COLOR с соответсвующими цветами связанной первичным id c первой таблицей по этому полю
естественно при выборке по этой таблице SELECT'ом быстрее искать по полю int, т.е второй вариант, но придется тратить время на выборку из вспомогательной таблицы при формированиее например HTML списков <select><OPTION>...т.е. нужно постоянно обращатся к отдельной таблице цветов чтоб узнать его буквенное значение.
Насколько это опраданно?
Развейте сомнение, что я сделал все правильно.
Спустя 1 час, 37 минут, 30 секунд (20.09.2011 - 07:29) kirik написал(а):
Т.к. цветов не много, а записей в основной таблице может быть много, то выноси цвета во вторую таблицу - в скорости почти не проиграешь (т.к. джоин второй таблице будет протекать моментально, из-за малого количества данных в ней), зато место на диске сэкономишь 
UPD
Но вторая таблица в реальной жизни не всегда будет выгоднее, не забывай.
UPD
Но вторая таблица в реальной жизни не всегда будет выгоднее, не забывай.
Спустя 58 минут, 9 секунд (20.09.2011 - 08:27) GET написал(а):
| Цитата |
| Но вторая таблица в реальной жизни не всегда будет выгоднее, не забывай. |
kirik
Можешь привести пример?
Спустя 30 минут, 18 секунд (20.09.2011 - 08:58) kirik написал(а):
A.B.C.
Например таблица постов/новостей/топиков и таблица пользователей. И в той и в другой много записей; джоин будет ресурсоёмкой операцией (даже по индексам). Плюс к этому, имея пользователя с id = 100000 - мы имеем 6 символов (примерно средняя длина юзернэйма). Тоесть в этом случае мы практически не выигрываем в размере, но значительно выигрываем в скорости исключая джоин.
НО! Как и в любом случае тут тоже есть минусы:
- меняя юзернэйм, придётся менять его во всех записях второй таблицы
- выборка (ака поиск) по юзернэйму будет более ресурсоёмкий, чем по ID
Всё очень сильно зависит от конкретного случая, и варианта на все случаи жизни тут не будет.
Например таблица постов/новостей/топиков и таблица пользователей. И в той и в другой много записей; джоин будет ресурсоёмкой операцией (даже по индексам). Плюс к этому, имея пользователя с id = 100000 - мы имеем 6 символов (примерно средняя длина юзернэйма). Тоесть в этом случае мы практически не выигрываем в размере, но значительно выигрываем в скорости исключая джоин.
НО!
Как и в любом случае тут тоже есть минусы:- меняя юзернэйм, придётся менять его во всех записях второй таблицы
- выборка (ака поиск) по юзернэйму будет более ресурсоёмкий, чем по ID
Всё очень сильно зависит от конкретного случая, и варианта на все случаи жизни тут не будет.
Спустя 23 минуты (20.09.2011 - 09:21) GET написал(а):
kirik
Большое спасибо
Большое спасибо
Спустя 55 минут, 8 секунд (20.09.2011 - 10:16) EvilDev написал(а):
Чтобы не плодить темы.
Есть таблица в которой id, имяфайла_картинки и пр.
Я вот думаю, может убрать id, и вместо его юзать имяфайла_картинки, как первичный ключ? На сколько это будет тормозно?
Если я не прав, то что будет, если закончится id?
Есть таблица в которой id, имяфайла_картинки и пр.
Я вот думаю, может убрать id, и вместо его юзать имяфайла_картинки, как первичный ключ? На сколько это будет тормозно?
Если я не прав, то что будет, если закончится id?
Спустя 3 минуты, 15 секунд (20.09.2011 - 10:19) Renden написал(а):
EvilDev
Если боишься что закончится id-шники тебе к санитарам Поставь bigint и Unsigned и 20 лет пытайся забить все id-шники
Если боишься что закончится id-шники тебе к санитарам
Поставь bigint и Unsigned и 20 лет пытайся забить все id-шники Спустя 20 минут, 18 секунд (20.09.2011 - 10:39) kirik написал(а):
EvilDev
Имея int(unsigned) у тебя может быть 4294967295 записей (4 триллиона?) и если фотка будет весить хотя бы 5 кб, понадобится 20 терабайт для хранения всех фоток. Сохраняя в день по 1000 фоток, тебе понадобится около двенадцати тысяч лет, чтобы забить БД.
Если я не напутл на ночь глядя с рассчётами, то ты зря опасаешься
bigint тут явно излишен. Беззнакового mediumint вполне должно хватить.
Имея int(unsigned) у тебя может быть 4294967295 записей (4 триллиона?) и если фотка будет весить хотя бы 5 кб, понадобится 20 терабайт для хранения всех фоток. Сохраняя в день по 1000 фоток, тебе понадобится около двенадцати тысяч лет, чтобы забить БД.
Если я не напутл на ночь глядя с рассчётами, то ты зря опасаешься
bigint тут явно излишен. Беззнакового mediumint вполне должно хватить.
Спустя 4 минуты, 27 секунд (20.09.2011 - 10:44) Renden написал(а):
kirik
Я обычно int использую для id навсякий случай (да и в чужих структурах обычно везде int), bigint юзал только 1 раз за все время, когда надо было хранить обьем файлов в байтах
Я обычно int использую для id навсякий случай (да и в чужих структурах обычно везде int), bigint юзал только 1 раз за все время, когда надо было хранить обьем файлов в байтах
Спустя 7 минут, 32 секунды (20.09.2011 - 10:51) kirik написал(а):
Renden
int - самый оптимальный варинат, ага. Хотя где хватит и меньшего поля, лучше использовать меньшее (быстрее выборка, меньше размер таблиц).
int - самый оптимальный варинат, ага. Хотя где хватит и меньшего поля, лучше использовать меньшее (быстрее выборка, меньше размер таблиц).
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.