ru.website

 
 - RU.WEBSITE -------------------------------------------------------------------
 From : Pavel Kurnosoff                      2:5030/736.25  15 Mar 2001  18:53:21
 To : iamhere@online.ru
 Subject : Re: Формирование картинки
 -------------------------------------------------------------------------------- 
 

 
  i> 1. Универсальный доступ - это ограничение интерфейса (набора методов),
  i> которых рано или поздно не хватит для доступа к фичам конкретной БД, если
  i> задача хоть сколько нетривиальна.
 
 да ну? ты про sql кодга-нибудь слышал? АБСОЛЮТHО все "фичи" любой б/д сводятся
 к выполнению запросов и получению ответов.
 
  i> 2. Если это СУпер-Гибкий интерфейс, то работать с ним - неудобно, так
  i> как СуперГибкий Интерфейс должен позволять задать ЛЮБЫЕ параметры
  i> коннекта, транзакции, запроса, должен поддерживать множество транзакций,
  i> вложенные транзакции, любые параметры запросов и результаты, должен уметь
  i> выдавать любую статистику по выполнению запрсов, поддерживать одну
  i> транзакцию у нескольких БД и один запрос на несколько БД. Hу что-то я
  i> наверняка забыл/не знаю. Ты себе представляешь такой интерфейс?
 
 такой интерфейс никому и нахрен не нужен. ВСЕ, что нужно от интерфейса -
 предоставить ДВЕ функции - perform_query и fetch_data. всё остальное - это уже
 другой уровень, на который ни dbi, ни odbc не претендуют.
 
  i> 3. Hу скажи мне - вот вы долго думали и решили - ваша система будет
  i> работать на Oracle. Или на DB2. Или на MySQL в конце концов.  Что -
  i> достаточно будет поменять БД и все заработает? Hе надо будет изменить
  i> много SQL-запросов (диалекты SQL разные!), хранимых процедур и триггеров,
  i> может даже структуру базы? Или у вас GuestBook - это все, что лежит в БД?
 
 понятно, у настоящих пыхапистов сверхпамать - они помнят названия и
 особенности всех дцати вариантов одной и той же функции. а мы - существа
 ленивые, мы один раз запомнили - и хватит. 
 
  i> 4. Единый интерфейс, это ограничивает развитие прослоек доступа к
  i> конкретным СУБД - чего ради совершенствовать модуль доступа, если все
  i> равно из-за ограниченности интерфейса? Почему, по твоему, кроме DBI пишут
  i> и DBI-несовместимые модули доступа к разным БД?
 
 писали. потому что тогда dbi не было. последний оплот идиотизма - ibperl уже
 тоже потихоньку отмирает, т.к. в dbd::interbase прогресс идет довольно
 уверенно. ты опоздал - все нынешние 'DBI-несовместимые интерфейсы' (кроме
 ibperl) - это на самом деле обертки для dbi.
 
 OBSOLETE SOFTWARE
        As of Msql-Mysql-modules 1.19_10 M(y)sqlPerl is no longer
        a separate module.  Instead it is emulated using the DBI
        drivers. You are strongly encouraged to implement new code
        with DBI directly. See the section on COMPATIBILITY NOTES
        below.
 
  i> А все преимущества - легко переменести guestbook. Смешно.
 
 нет. все преимущества - не запоминать, а как у нас нныче называется функция
 "выполнить запрос".
 
 зы: ты про odbc слышал? тоже идиоты делали? это ты обратись к Долгову или
 Шикову - они на примерах тебе подробно разяснят все и для этого случая. я,
 каюсь, прошел мимо технологий работы с базами данных под win32.
 -- 
 // pavel kurnosoff 
 --- Gnus v5.6.45/XEmacs 21.1 - "Bryce Canyon"
  * Origin: there's no tomorrow (2:5030/736.25)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор