Это понятно. Я спрашивал несколько иное: что выбрать, ИП или ООО? Подойдет ли тут УСН? Какой объект выбрать для налогообложения, доход или доход за вычетом расходов? Не будет ли проблем с тем, что исполнители, по сути, получают зарплату, с которой тоже должны уплатить налог? А может вообще можно оформиться как не резидент РФ и это даст какие-нибудь преимущества?
Это не всегда так. Если есть набор настроек, например, какие-то галочки у пользователя, то лучше (экономнее, производительнее) их хранить как битовую маску. Если у этих галочек 3 положения, то для хранения вполне подойдут строки (хотя, если действительно задумываться о производительности, то подойдут Nричная система счисления, где N количество положений).
Да, все это противоречит второй нормальной форме, но как говорится, только ситхи возводят все в абсолют.
@DmitriyEntelis: хм. Результаты с лайком довольно неплохие, но, похоже, прирост времени у лайка гораздо больше, чем у регэкспа. Вероятно, на 20 миллионах, он обойдет лайк. И это не считая того, что для реализации шаблона лайка недостаточно, а использование чего-нибудь типа SUBSTR или LEFT, RIGHT видится сущим адом.
Интересно было бы взглянуть на производительность тех же запросов на BIGINT место VARCHAR. Для реализации первого лайка, пойдет что-нибудь такое, я думаю:
... WHERE `title` BETWEEN 7903090996 AND 7903099996
Хотя, следует заметить, что лайк искал по большему диапазону. Эквивалентом было бы '790309_996'.
@DmitriyEntelis: хранить цифры в юникоде, действительно, ни к чему, но ведь приятно, когда вся база в одной кодировке, верно? По поводу цифр - их может быть и 16. Номера будут не только русские.
Тесты интересные, но таблица будет InnoDB (точнее, XtraDB). К тому же, не сказать, что 0.24 sec это достаточно быстро. Нужно это сравнить хотя-бы с обычным статическим запросом, типа `title` = 'номер', какое он выдаст время? Что-бы иметь мало мальское представление о производительности вашего железа в целом.
@DmitriyEntelis: вообще байт будет как минимум 32 (16 символов в юникоде), но вообще, да. Не так уж и много оно занимает. А будет ли это достаточно производительно? Операции со строками в MySQL не самые быстрее.
Это основная информация, которую придется хранить, так что экономить место смысл есть. На 100 000 это может и не будет заметно, но на 1 000 000, думаю, разница будет значительной.
@Tyranron тоже думал над дополнительными полями место блокировок, но они понадобятся не только в таблице исполнителей, но и в остальных (например, что бы исполнитель или заказчик не смог сменить цену во время обработки запроса).
По поводу NULL'ов, это как-то не эстетично. К тому же лишний байт на каждое поле.
