ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] Re: [apache-rus]=?koi8-r?B?7tXWzsEgy8/S0sXL1M7B0SDT19Hay8EgQXBhY2hlLVJVUyBQSFAgUGdTcWw=?==?koi8-r?B?IFBlcmw=?=





On Fri, 5 Oct 2001, Victor Wagner wrote:

> On Thu, 4 Oct 2001, Viktor M. Gnitiyov wrote:
>
> > Кстати, вопрос 2 к тем, кто имел реальный опыт с базами данных.
> > Обращения к серверу БД предполагаются простые: максимум второй уровень
> > вложенности и без использования спец-функций (чистый SQL-92). Какую
>
> Я фигею от такой простоты!
>
Гы...

> Чистый SQL92 не поддерживается в полном объеме по-моему ни одним
> SQL-сервером, начиная с Oracle!
>
Именно так. На настоящий момент в мире не существует НИ ОДНОЙ базы данных,
поддерживающей SQL-92 в полном объеме. Увы. Кстати ближе всего туда
подходит таки MySQL, хотя местами это "совместимость ради совместимости":
команды мы ANSI-шные понимаем, только вот большУю часть там написанного
игнорируем :-)

Вообще, соотвественно, следует смотреть на ВСЕ доступные варианты (хотя
бы вкратце). Так как SQL-92 вам никто не даст, то смотрите то, что есть и
решайте - хватит вам или нет. MySQL требует меньше ресурсов, чем
PostgreSQL и быстрее, но если вам не хватит возможностей и придется
создавать временные таблицы, то его преимущество в скорости потеряется.
Хотя НА САМОМ деле во многих случаях можно обойтись некоторыми MySQL'ными
расширениями вместо 100% ANSI SQL-92 -- и это будет ЗНАЧИТЕЛЬНО быстрее
(собственно это верно в отношении почти что любой базы - потому никто
особо в ANSI SQL-92 и не упирается: "зачем? все равно ведь вы наши
расширения будете использовать и программа ваша не будет переносима")...

> Кстати, PostgreSQL местами ближе к ANSI 92 чем Oracle. Например, у него
> синтаксис внешних соединений ANSI-шный.
>
> Рекомендация по поводу FireBird вообще говоря заслуживает рассмотрения.
> Если не боишься всяких его security hole - hardcoded администраторского
> пароля, множественных buffer overflow etc.
>
> В принципе на web-сайте SQL-сервер все равно должен слушать только на
> localhost, а еще лучше - вообще на Unix domain socket-ах, как я всегда
> настраиваю Postgres. Так что это не страшно. Обеспечение безопасности
> возьмет на себя middleware - php и perl скрипты.
>
> Но вот с чем у FireBird плохо, так это с DBD-драйерами для Perl.
> Во всяком случае еще полгода назад было плохо.
>
> Поэтому, если активно использовать Perl, то я бы предпочел PostgreSQL.
> Что касается требований к ресурсам, то они у него вполне приемлемые.
>
> Помнится я как-то убил на месте одну команду виндузячих web-программистов,
> продемонстрировав им web-сайт с модперлом и https-ом и кучей графиков
> строившихся run-time из постгресовой базы,
> выполнявшийся на Pentium 100/16Mb RAM/850Mb IDE HDD.
>
> Правда, то был Postgres 6.4.2. У 7.1.3 системные требования таки повыше.
> Пожалуй 32 мега понадобится.

При сегодняшней цене на память это смешно. И 16Mb и 32Mb. Я не говорю, что
раз память дешевая - можно ее транжирить. Но и проявлять чудеса
эквилибристики заводя свой сайт на 16Mb, когда в любой Pentium можно
вставить 64Mb, а в что-то посовременнее - 512Mb или 2-3Gb я не вижу
смысла.


=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.