Оптимизация работы с базой данных
а если серьйозно, то читать об Нормализации БД
Ты чего-то городишь не то. В практически любой СУБД - время примерно одинаково. Накладные расходы - только на доступ к диску.
Но чую я, у тебя неверное представление о БД и механизмах работы с ними.
Ну все нормальные СУБД сами заботятся об индексации и т.д и тп. но теоретически БД должна быть нормализирована..
Да никто ж и не спорит... ;) Нормализация хороша и для скорости выборки и для размера базы.
Какое отношение нормализация имеет к индексации?
Афтор - это:
вопрос или утверждение?
Интересная какая связка.
А как ты примерно представляешь структуру такой записи, да и вообще базы?
А как ты примерно представляешь структуру такой записи, да и вообще базы?
я честно говоря вас обоих не понял - и мне такой травы отсыпте :)
:) Ну, смотри. Утверждение:
[quote=аффтар]
В любой программе, скорость отображения на экран записи идентифицируемой ключом id, имеет прямую зависимость от количества записей в базе при условии, что скорость добавления (вставки) новой записи - независима от размера базы данных.
[/quote]
Вот я и спросил, как аффтар представляет себе такую базу? Ибо есть мнение, что она ему представляется в виде зеленого дракона на фоне розового Собора Парижской Богоматери в зеленых лучах предзакатного солнца.
Кхе... Там еще такой хорошей травы нету? :rolleyes:
Нет такой травы нам не надо. Своих тараканов некуда девать =)
Такое ощущение, что топик-стартеру и не нужны никакие ответы, он вполне самодостаточен и сам себе делает утверждения...
От себя автору могу сказать одно: забить ... взять любую базу, она самая лучшая, и не парить мозг такими вещами.
Она зависит от реализации слоя представления данных и сложности UI-компонент.
Скорость выборки записи из базы - автору надо это.
Если таблица проиндексирована и индекс целиком может быть кеширован в памяти (что для маленьких и некластерных баз вероятно верно), то скорость выборки одной записи по индексированному полю - близка к постоянной (если не брать в расчет доступ к диску).
Время же вставки в таблицу да, увеличивается с увеличением размера таблицы, т.к. надо перестроить индексы (в том числе). Но для одной записи это не очень большое увеличение. Вы его не заметите.
Короче, пока автор не скажет, сколько у него строк в базе, наверное мы так и будем толочь воду в ступе?
Автор, как насчет прояснить задачу и свои размеры? Данных.
Если более четко изложить тот метод который интересует, то думаю, вариант найдется. Еще неплохо бы знать задачу.
Вставка, верней добавление - элементарно. Пиши в конец файла с данными, и строй индекс. Выборка, соответственно, по индексу. Вопрос быстродействия, сводится исключительно к структуре, и организации работы с индексом.
Ты что-то уже тестировал? Сравнивал? Какие результаты?
Это интересно не столько временем выполнения запросов. А следствием. Например быстрая графика.
А что ты собрался отрисовывать такого, что требуется шустрая выборка 5000000000000 неких записей в базе? Моделирование некой ядерной реакции? Тык, там по другому принципу визуализация выполняется.
Что-то из тебя выдавливать все приходится. Зависит, разумеется. Если тупо рисовать всю "вселенную", то слайд-шоу для мазохистов обеспечено. Для этого и применяются дополнительные технологии и структуры данных. quadtree, octree, LOD, mipmapping и дикая куча других. Видишь ли, если "вселенная" теоретически бесконечна, то память и быстродействие вычислительной техники имеет такие барьеры, и не в технологии выборки здесь дело. Ты бы что-нить про визуализацию больших объемов данных почитал, чтоб представление иметь.
Соглашусь с GreenRiver в том, что тебе просто поп%здеть охота. Ты - либо полный ноль в чем бы то не было, либо тупо стебешься, пытаясь вывести кого-либо из участников из себя.
в школу, за парту..
как бе нет. как раз таки для скорости часто приходится выполнять ДЕнормализацию
Согласен. Запутали, обманули, заставили.