Хотел бы задать такой странный вопрос. Формирую файлы, точнее ресайзом создаю новые картинки и затем присваиваю им имена. Очень удобно сделать имя файла (без пути) в 50-80 символов длинной, включить в название кое-какое описание (само собой на латинице).
Эти названия + пути заносятся в БД, в поле varchar(255).
Собственно в этом вопросы:
1. Если строк, скажем 10 тысяч, будет ли существенно легче базе хранить строки со значениями полей длинной 10-15 символов, против 50-80 символьных?
Выборка, конечно, будет осуществляться по id строк, а не самим им.
2. Насколько удобнее операционной системе искать более короткие имена на HDD?
Спустя 6 минут, 32 секунды (9.05.2011 - 16:48) Игорь_Vasinsky написал(а):
| Цитата |
| включить в название кое-какое описание. |
| Цитата |
| имя файла (без пути) в 50-80 символов длинной |
для чего такое? не проще файлы грузить в определённые директории, придумывать для них индексы, например i1231.png, или даже если конвертирование сразу идёт (в jpg) то в базе и без расширения хранить можно
Спустя 10 минут, 13 секунд (9.05.2011 - 16:58) GET написал(а):
Игорь_Vasinsky
Можно проиндексировать конечно, но для этого нужно еще одну таблицу создавать. Файлы эти и так храняться в определенных директориях. От расширения тут избавиться нельзя т.к. два типа используется...png и jpg, пути, конечно можно убрать, но т.к. конечная папка для разных юзеров разная, то придется эти пути заново вычислять...удобнее все же было бы прямо целеком ложить...
Можно проиндексировать конечно, но для этого нужно еще одну таблицу создавать. Файлы эти и так храняться в определенных директориях. От расширения тут избавиться нельзя т.к. два типа используется...png и jpg, пути, конечно можно убрать, но т.к. конечная папка для разных юзеров разная, то придется эти пути заново вычислять...удобнее все же было бы прямо целеком ложить...
Спустя 3 минуты, 50 секунд (9.05.2011 - 17:02) Игорь_Vasinsky написал(а):
ну если так принципиально что длинные имена, и разные папки для юзеров - то мне кажется оптимально всётаки ещё одну таблицу создать для этого дела:
id_user | name_pic
id_user | name_pic
Спустя 2 минуты, 51 секунда (9.05.2011 - 17:05) GET написал(а):
Спасибо...буду думать, возможно действительно придется создать.
Спустя 7 минут, 21 секунда (9.05.2011 - 17:13) Игорь_Vasinsky написал(а):
ну сам подумай - зачем хламит в таблицу, когда можно всё удобненько разделить
Спустя 3 минуты (9.05.2011 - 17:16) Zerstoren написал(а):
Такс, чтоб все было быстрее - стоит хранить файлы с пространством имен близко 16 символов. Но будет к примеру 256 папок (первые два символа хэша)
Но это если картинок будет 150к+
В 16 символов пространства будет 1,427,343,499,466,749,467,68,896 вариантов имени файлов. (38 *символы a-z0-9* в 16 степени)
Если картинок будет 50-500 то используйте СЕО вариант,
имя картинки формируется с названия страницы, если картинок несколько то в конце дописывайте name-1, name-2,name-3, а еще они должны хранится в одной папке. И не забывайте что у картинки должен быть альт и тайтл и они должны разниться, хотяб одним словом.
Все что сказано про СЕО рекомендации гугла и яши.
Но это если картинок будет 150к+
В 16 символов пространства будет 1,427,343,499,466,749,467,68,896 вариантов имени файлов. (38 *символы a-z0-9* в 16 степени)
Если картинок будет 50-500 то используйте СЕО вариант,
имя картинки формируется с названия страницы, если картинок несколько то в конце дописывайте name-1, name-2,name-3, а еще они должны хранится в одной папке. И не забывайте что у картинки должен быть альт и тайтл и они должны разниться, хотяб одним словом.
Все что сказано про СЕО рекомендации гугла и яши.
Спустя 48 минут, 49 секунд (9.05.2011 - 18:04) ИНСИ написал(а):
| Цитата |
| Очень удобно сделать имя файла (без пути) |
Конечно же! В БД надо хранить лишь имя файла.
| Цитата |
| Эти названия + пути заносятся в БД, в поле varchar(255). |
Не советую для имени создавать varchar(255). Можно сделать: varchar(15) и там хранить лишь имя.
Спустя 8 часов, 9 минут, 59 секунд (10.05.2011 - 02:14) GET написал(а):
Всем огромное спасибо за советы.
_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.