edogs
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата: А что тогда предлагали? Обращаться в базу.... брать от туда id, дату и т.д ... а текст брать с файла? | Угу. Наконец-то разобрались Цитата: По моему что в базе.... что в файле... KB занимаемой текстом памяти от этого не изменится.... | Смотря как строить скрипт, если "тупо" - "все что выбрал - загнал в память - и вперед", то да, не изменится. Цитата: Откуда цифры? Где аргументы? Где написано такое? | В отквоченной Вами цитате были вопросы к Вам... на которые Вы не ответили. Аргументы были выше и ниже. Цифра 1.5М взята из первого поста автора. Цифра в 64Кб была взята как минимальная учитывая разговоры автора о БОЛЬШОМ тексте... т.е. не меньше размера поля text (даже не longtext). Впрочем даже её уменьшение 4 принципиально ничего не изменит. Цитата: згаешь... я ведь тоже к твоим словам могу писать "фигня, где аргументы" | Можешь, только тогда нам придется давать линки на посты с ними, или повторять их заново, зачем? Мы этого делать не будем. Ответьте пожалуйста на простой вопрос - зачем устраивать из таблиц помойку храня там всё и вся? Зачем раздувать размер одной таблицы храня там чисто СТАТИЧЕСКУЮ информацию над которой НЕ производится никаких СЛОЖНЫХ операций? Зачем прогонять лишний объем данных через мускульный интерфейс когда можно напрямую обратиться к файлу? Зачем лишать себя возможности в будущем добавив неиндексируемое поле устроить по нему поиск (на большой базе table scan менее реален)? Цитата: я не вижу ни одного плюса в сторону хранения картинок в базе... | мы не видим ни одного плюса в сторону хранения большого текста в базе... А текст и картинки это одно и то же - данные. Так значит Вы с нами согласны? Ну и о чем было спорить? На этом и закончим для себя здесь участие. Напоследок просто пару цитат из мануала, не всегда правда имеющих прямое отношение к обсуждаемой теме, но выводы сделать можно http://dev.mysql.com/doc/refman/4.1/en/data-size.html One of the most basic optimizations is to design your tables to take as little space on the disk as possible. Create only the indexes that you really need. In some circumstances, it can be beneficial to split into two a table that is scanned very often. This is especially true if it is a dynamic-format table and it is possible to use a smaller static format table that can be used to find the relevant rows when scanning the table. Добавлено: Цитата: На любом нормальном хостинге, PHP соединяется с MySQL посредством unix-pipe. Это не медленнее файлов. | Почему-то многие уверены что mysql хранит свои данные не в файлах, а в некоем абсолютно быстром пространстве. Но это не так. Цитата: Я может и не привожу аргументов, в твоем понимании, | Не знаем в чьем понимании кроме Вашего "мускул писали грамотные люди поэтому все надо хранить там", "мускул крут тем что умеет кэшировать и прочую хрень" это может быть аргументом. Цитата: но и не пишу бреда, типа выборок по 1.5М*64кб | И мы этого тоже не пишем. А кто это пишет? Давайте объясним что он не прав P.S.: Всё, нас в этой теме больше нет. Добавлено: В личке по этому топику ответим если вдруг... |