Доброго времени суток, многоуважаемые коллеги. Передо мной встала такая задача - написать скрипт, который динамически формирует некоторый файл и отдает его клиенту. В принципе, с самим написанием такого скрипта проблем нету, но файл может получиться большой и у клиентов с нестабильной связью можгут возникнуть проблемы с его загрузкой. Отсюда вопрос, как мне реализовать в данном скрипте поддержку докачки??? Заранее спасибо.
Добрый день, Gibbel! мой тебе совет: формируй этот файл и выкладывай его на диск, в каталог ФТП-сервера. И пусть юзеры его оттуда тянут. Тут уже и специальные программы закачки можно использовать и тд. Ответ отправлен: 23.01.2004, 16:29 Отправитель: Dimonuch
Вопрос № 140
Здравствуйте! У меня вопрос по оптимизации PHP+MySQL. В БД хранятся строки, которые могут повторяться. Их можно удалять. Для этого в таблице каждой строке соответствует уникальный номер. Изначально номера идут подряд: 1 2 3 4 5 6 7 После удалений пространство номеров сожержит "дырки": 1 3 6 7. Поэтому при добавлении новой строки я ищу свободный идентификатор, начиная с 1, делая это из PHP-сценария. Вопрос1: Не будет ли такая схема "тормозить" при значительном количестве строк (~100000)? Вопрос2: Как оптимально идентифицировать записи в БД MySQL для быстрого их добавления? Вопрос3: Можно ли эту работу (поиск подходящего идентификатора) "поручить" СУБД, а не сценарию?
Доброе время суток, Александр! все неправильно. Ни в коем случае не делай так. Представь сколько запросов будешь делать по больших значениях. Такой вопрос решается по-другому. Мускул сам может вести идентификаторы записей. Для этого достаточно, создавая таблицу мускула, указать что-то типа: create table admins ( id int not null auto_increment primary key, login char(12) binary not null } Поле id будет уникальным идентификатором. Мускул сам будет назначать его при добавлении записи. Тебе даже думать об этом не нужно. Ответ отправлен: 25.01.2004, 23:02 Отправитель: Dimonuch Отвечает samum2000
Здравствуйте, Александр! 1. Мне думается, что при значительном объеме строк такая операция действительно будет тормозить, особенно если эти дырки окажутся где-то в конце. Я вижу несколько выходов. Во-первых, можно иметь дополнительную таблицу, в которой будут перечислены дыры, и в дальнейшем не производить поиск, а брать значения оттуда. Во-вторых, можно просто оставлять дыры, и добавлять записи в конец таблицы, а затем периодически проводить "переиндексацию" таблицы. 2. Не совсем понятно про оптимальную идентификацию записей - у тебя же есть уникальное поле, значит с идентификацией проблем быть не должно, а скорость здесь вообще не причем. 3. ИМХО, нет. Ответ отправлен: 25.01.2004, 12:38 Отправитель: samum2000
Форма отправки вопроса
Внимание!
Мы рекомендуем открывать рассылку в программе Internet Explorer 5.0+
или отправлять вопросы с сайта по адресу:
http://rusfaq.ru/cgi-bin/Message.cgi.