forum.lissyara.su

есть таблица:


convert_vf - это конвертированный файл
null, - это положительно, 0 отрицательно

как правило больше будет значени с null

===

тут как бы правильно, сделать еще одну таблицу:
( а в предыдущей таблице удалить convert_vf )
подскажите, с точки зрения правильности, обязательно ли делать 2 таблицы, или можно одну таблицу?

при каких нагрузках или размерах таблиц может быть разница в производительности? (если таблица 200Гиг?)
если это "пофиг", то может лучше сделать одну таблицу?

Что-то я не уловил. Связь один к одному? А какие запросы в основном будут?

просто везде в таблице будет стоят convert_vf null

смысл делать строку где почти везде будет одно значение?

а если сделать еще одну таблицу, то там поставить:

convert_vf null
и id через join обядинить

2 возможных значения:
1) null будет положительное
2) а если вообще записи нету, то отрицательное

===

запрос WHERE convert_vf != 0

===
я бы хотел спросить с точки зрений праивльности, я затрудняюсь выбрать правильный вариант... (если разница нету - то значит оба правильные)

Насколько я знаю Мускуль очень хорошо работает с НУЛ-значеними. Я бы делал все в одной таблице. Потому, что если будет связь, то это будут еще и индексы, не знаю, получиться ли экономия.

мне один человек рассказывал, говорил что лучше делать 2 таблицы... будут какие дырки в хранилище
(наверное про MyISAM такое)

а запрос можно без join, а просто по id сравнить с двух таблц

ок, сделаю тогда 1 таблицу...

там навреное надо тестирвоать в любом случае, а если таблица будет 200гиг, то тогда отказатся от MySQL вообще

Тип хранения таблиц какой планируется?

MyISAM

А запросы какие предполагаются? Если сначала только
с таблицы video_files_convert (
`id_vf`mediumint(9) NOT NULL,
`convert_vf` tinyint(1) default NULL,
PRIMARY KEY (id_vf)
);
а потом уже остальную инфу, то возможно, что 2 таблицы все же будет лучше.

Я предлагаю избавиться от varchar'ов. С ними работает медленней, да и вроде как MyISAM собирается товарищ использовать, а там какие-то фрагментации таблиц начинаются с варчарами.. Ну и id_va и id_un предлагаю сделать индексами.

goshanecr писал(а):С ними работает медленней, да и вроде как MyISAM собирается товарищ использовать, а там какие-то фрагментации таблиц начинаются с варчарами..

это не спасёт, если база криво сделана. Фрагметнации - это проблемы муси и файловой системы, база должна быть спроектирована правильно, тогда будет толк.

ProFTP писал(а):подскажите, с точки зрения правильности, обязательно ли делать 2 таблицы, или можно одну таблицу?

с точки зрения правильности только тип связи "один-к-одноиу" можно запихнуть в одну таблицу. Если тип "один-ко-многим" или "многие-ко-многим", то только две таблицы.

Gamerman писал(а):Насколько я знаю Мускуль очень хорошо работает с НУЛ-значеними.

его не рекомендуют использовать без надобности, поскольку это дополнительная нагрузка, особенно в индексах. Для булева типа нужно использовать TINYINT(1) NOT NULL и не иначе.

ProFTP писал(а):null, - это положительно, 0 отрицательно

самое неправильное решение, которое тут можно только придумать.

goshanecr писал(а):Я предлагаю избавиться от varchar'ов. С ними работает медленней, да и вроде как MyISAM собирается товарищ использовать, а там какие-то фрагментации таблиц начинаются с варчарами.. Ну и id_va и id_un предлагаю сделать индексами.

а так достаточно PRIMARY KEY (id_vf, id_va,id_un ) как раз и уникальность и индекс будет, правильно?

zg писал(а):самое неправильное решение, которое тут можно только придумать.

я сделал так: 0 и 1

но например мне говорили:
(я не отрицаю и не поддерживаю)

1) есть например, 1 - будет больше чем 0 в поле ro

то можно сделать еще одну таблицу и туда написать id, ro

при этом ro будет как NULL

если запись есть IS NULL - то это положительное, а если нету, то отрицательное


2) еще варинта, и этот вариант я видел в движке SMF (сильно не интересовался)

где NULL - это один полюс
а 0 - это другой полюс

при запросе SECELET IFNULL(t1.ro,1) это означает, что NULL будет как 1

NULL в идексах не участвует, возможно оно будет быстрее? но не обязательно
и по-моиму NULL это 1 бит ровно, а 1 и 0 ит.д. это от 6-10 бит

===

на я так понял что это фигня на счет 0 1 NULL, фиг с ним, короче

а так достаточно PRIMARY KEY (id_vf, id_va,id_un ) как раз и уникальность и индекс будет, правильно?

Судя по названиям полей id_va, id_un - они являются идентификаторами чего-то там, что хранится в другой таблице... Если это так, то лучше всё таки по отдельности сделать их индексами, а id_vf - Primary key.

goshanecr писал(а):

а так достаточно PRIMARY KEY (id_vf, id_va,id_un ) как раз и уникальность и индекс будет, правильно?

Судя по названиям полей id_va, id_un - они являются идентификаторами чего-то там, что хранится в другой таблице... Если это так, то лучше всё таки по отдельности сделать их индексами, а id_vf - Primary key.

а если у меня эти 3 поля должны быть уникальными

то можо так KEY unik ( id_vf, id_va,id_un ) ?

unik - это будет имя ограничения уникальности имя ограничения уникальности

а зачем нужны 3 числовых поля, да ещё и чтобы все три были уникальными? В данном случае, с базой видеофильмов, какой в них закладывается смысл?

я имею ввиду что все 3 вместе должны быть уникальными

чтобы НЕ было так
1 2 3
1 2 3

чтобы можно было

1 2 3
2 2 3
3 1 3

для этого KEY unik ( id_vf, id_va,id_un ) ?