Всем привет. Всех с наступившим.
Вопрос. Существует система на php+mysql ,в ней могут регистрироваться множество пользователей. Эти пользователи могут добавлять в систему свои записи. От пары символов до текстов по объему равных Войне и миру.
Функционал системы -добавление записей, вывод записей конкретного пользователя, поиск по записям конкретного пользователя. Вывод всех пользователей, поиск по записям всех пользователей. Ориентировочно 1 пользователь будет добавлять в год от 500 текстов +-.
Вопрос -как организовать таблицу хранения данных записей, какие ключи, индексы и прочие темы использовать?
Вариант
id | name | text | user_id
я бы не стал заморачиваться и мучить форум глупостями, но объем текстов предполагается разнообразный и заливать будут в том чисел очень большие тексты и количество текстов будет огромное. Не хотелось бы ошибиться изначально
Полная Версия: организация таблиц для хранения текстов
ну для огромных текстов есть тип TEXT и связанные с ним в бд, не говоря уже про просто BLOB.
И, кстати, что такое огромные текст?
Так-то война и мир в чистом виде занимает ~3мб(первая что нагуглил). Это совсем не много и легко вместится в стандартный LONGTEXT.
Ну а для текстов, которые больше LONGTEXT-а можно проверять размер и бить на части, и писать в соотв-ю табличку частями.
_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."
Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. © AllesKlar
И, кстати, что такое огромные текст?
Так-то война и мир в чистом виде занимает ~3мб(первая что нагуглил). Это совсем не много и легко вместится в стандартный LONGTEXT.
Ну а для текстов, которые больше LONGTEXT-а можно проверять размер и бить на части, и писать в соотв-ю табличку частями.
_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."
Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. © AllesKlar
vital
т.е. фактически для больших текстов должна быть доп таблица?
т.е. фактически для больших текстов должна быть доп таблица?
| Цитата (hurt3 @ 2.01.2015 - 20:18) |
| vital т.е. фактически для больших текстов должна быть доп таблица? |
Если вдруг у вас будет текст, который больше чем тип LONGTEXT (что вряд ли, война и мир короче в полтора-два раза), то да, стоит вынести текст - как отдельную сущность, соотв-но дробить тексты на части, и писать в эту таблицу храня соотв-е каждой части к какой сущности эта часть относится и какая она по порядку.
НО.
Если не критично время ответа страницы (если 10-20-30ms не критичны для вас, а я думаю не критичны), как вариант попробуйте ваши тексты просто жать каким-нить зипом при записи, и при выводе распаковывать, а писать соотв-но просто в BLOB. Тексты очень хорошо и, я думаю, быстро жмутся. Вряд ли вы встретите текст, который сжатый в зип выйдет из размеров LONGBLOB. Но да, с точки зрения универсальности и надежности первый вариант правильнее.
А еще.
А вы уверены что вам надо mysql ?
Возьмите какой-нить Redis, у него максимальный размер строки вообще 512мб. Это пол-интернета в тексте. Да и удобнее работать вам будет, чем с SQL в данном случае, имхо.
_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."
Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. © AllesKlar
vital
благодарю
благодарю
| Цитата (vital @ 2.01.2015 - 21:27) |
| 512мб. Это пол-интернета в тексте |
В несжатом виде база сообщений нашего форума больше гигабайта.
_____________
Бесплатному сыру в дырки не заглядывают...
| Цитата (vital @ 2.01.2015 - 22:27) |
| [QUOTE=hurt3,2.01.2015 - 20:18]...тип LONGTEXT (что вряд ли, война и мир короче в полтора-два раза)... |
| Цитата (hurt3 @ 2.01.2015 - 15:54) |
| id | name | text | user_id |
можно id объединить с user_id сделав ключ составным по id и name. Вопрос
| Цитата (hurt3 @ 2.01.2015 - 15:54) |
| как организовать таблицу хранения данных записей, какие ключи, индексы и прочие темы использовать? |
упирается в вопрос: каков бюджет мероприятия?
| Цитата (FatCat @ 2.01.2015 - 21:35) | ||
В несжатом виде база сообщений нашего форума больше гигабайта. |
Я люблю утрировать, да. Ну так-то база форума не связанный текст, и собрана годами, и блаблабла. Короче давайте лучше занудамоде=офф
_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."
Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. © AllesKlar
| Цитата (S.Chushkin @ 2.01.2015 - 22:01) | ||
А если почитать доку? |
| Цитата |
| LONGTEXT Максимальная длина 4 294 967 295 символов |
Для однобайтной кодировки 1 символ = 1 байт(можете проверить с помощью блокнота), для боговерного двухбайтового юникода 2 соответственно.
Ну разделите на 1024 несколько раз, приняв что размер войны и мир меньше 3х мб.
Где я не прав? Что не соотв-т доке?
_____________
"Нужно быть готовым прислушиваться к тем, кто может тебя чему-нибудь научить. Иначе ты никогда не вырастешь."
Откровенно я никому ниразу не нагрубил. А дать подзатыльник зарвавшемуся юнцу, так это и ему на пользу, и мне в удовольствие. © AllesKlar
| Цитата (mvg @ 2.01.2015 - 23:16) |
| можно id объединить с user_id сделав ключ составным по id и name. |
я бы этого не делал, и другим бы не советовал
id с user_id составной уникальный можно сделать
_____________
Стимулятор ~yoomoney - 41001303250491
| Цитата (vital @ 3.01.2015 - 00:45) |
| Где я не прав? |
Быть Вам финансистом Партии и Правительства! ... во веселуха будет
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
| Цитата (vital @ 2.01.2015 - 23:41) |
| Короче давайте лучше занудамоде=офф |
Не получится. Потому как топикстартер некорректно поставил вопрос. Ничего не сказано о целях хранения информации.
На примере движка этого форума, у нас существуют 3 параллельных способа хранения информации:
1. В БД текстовые поля - доступные поиску.
2. В gz-файлах. Для экономии дискового пространства. Для больших текстов. Есть возможность поиска средствами пхп.
3. Зазипованные в БД в поле blob. Для маленьких текстов. Потому что если их хранить в файлах, будут большие потери на кластеризации.
_____________
Бесплатному сыру в дырки не заглядывают...
| Цитата (Valick @ 3.01.2015 - 00:29) | ||
я бы этого не делал, и другим бы не советовал id с user_id составной уникальный можно сделать |
id === user_id и тогда id | name | content, private key (id, name) будет состоять во 2 н.ф. что не так плохо. Если конечно это высоко нагруженный проект тогда надо по другому, но так как человек хочет что-то простое, для душу смастерить то в самый раз.
mvg, это сделает невозможным добавление двух текстов с одинаковым названием, плюс ко всему индексация по числам гораздо шустрее, чем по строкам. В итоге два минуса, против сомнительной экономии дискового пространства... не густо.
Вы правда хотите со мной поговорить о нормальных формах ?
_____________
Стимулятор ~yoomoney - 41001303250491
Вы правда хотите со мной поговорить о нормальных формах ?
_____________
Стимулятор ~yoomoney - 41001303250491
Здесь расположена полная версия этой страницы.