скажи НЕТ субд! Наши разработки. Software. ГП ДПИ.

Вы здесь:   >ГП ДПИ   >Software   >Наши разработки   >скажи НЕТ субд!

Вообще-то автор в курсе, что термины "бд" и "субд" обычно принято писать с большой буквы. Столь явное пренебрежение этим правилом вызвано лишь неутолимым желанием продемонстрировать свое отношение к этим терминам, а также к тому что за ними скрывается на самом деле. Автор заранее приносит свои извинения, если его мнение покажется слишком резким или оскорбительным.
 
  Меня чертовски достали разговоры как "прикрутить" бд к ЛИСПу, какие бд лучше использовать, обсуждение всевозможных тонкостей и чем некий подход лучше стандартного ACAD-овского ase. Еще больше меня заводит тот факт, что эти разговоры ведуться людьми давшими себе труд ознакомиться с ЛИСПом. У меня в сознании просто не укладывается тот факт, КАК человек, изучивший ЛИСП, может всерьез задаваться таким вопросом???? Если кто-то решил, что я сейчас буду защищать стандартный метод компании Автодеск - тот может раслабиться, этого точно не будет. Приготовтесь услышать нечто гораздо более честное. Ну, как, готовы? Тогда, ВНИМАНИЕ:
ЛИСП НЕ НУЖДАЕТСЯ НИ В КАКИХ ВНЕШНИХ БАЗАХ ДАННЫХ !!!
Если кто-то НЕ согласен, читайте дальше и постарайтесь понять суть сказанного. Тем кто это понимает и без меня, читать дальше не обязательно, разве что из интереса.
 
  Попытаюсь для начала сформулировать причины по которым я так считаю:

Думаю, что большинство жаждет поспорить, однако прежде выслушайте аргументацию до конца. Думаю, что стоит несколько подробнее остановиться на названных выше причинах. Начнем, пожалуй, с ассоциативного списка. Подумайте хорошенько, чем по своей сути является набор пар "ключ-значение"? Ничего не напоминает из области бд, а? А чем по Вашему является функция assoc? Если отбросить мелочи (вроде синтаксиса и тому подобные), то большинство из Вас должны согласиться что ЛЮБАЯ база данных есть ни что иное как ассоциативный список, а функция аналогичная ЛИСПовской функции assoc - базовая (в смысле "элементарная", как "элементарная частица") функция поиска в ЛЮБОЙ субд. Любой, кто более-менее знаком с ЛИСПом без особого труда набросает схему функции с возможностями аналогичными SQL-евскому SELECT-у, но работающую с ассоциативными списками. Невелик труд, да и пользы особой от этого как то не очень много. Если совсем честно - один лишь вред. Признаться честно, был у меня такой грешок - пытался сделать нечто эдакое. Долго мучился (не от того, что проблема сложная), а от того, что как-то все неэстетично получалось. Пока не понял нельзя упрячь в одну повозку "коня и трепетную лань". Нет ни какого смысла в попытках лишить ЛИСП гибкости и динамизма. Скажите, а может ли, например, SELECT добавить новое поле в запись базы, если оно там не предусмотрено, а учитывать механизм наследования, а механизм вычисляемых значений, а с учетом нахождения недостающих для этого вычисления переменных. Этот перечень можно продолжать очень долго - его цель лишь намекнуть как ограничены обычные субд по сравнению с ЛИСПом.
((m-t "<ДВТР_>")
     (m-h "SRTM(DWTR0)" srtm_pt)
     (sokr t)
     (prf "ДВТР" srtm_pt "BZ/DWTR0.BZ")
   )
   ( (nm "ДВТР_10")
     (ld* ((nm "ДВТР_10")) "bz/dwtr_.bz" srtm_pt)
   )
   ( (nm "ДВТР_12")
     (H         120.0)
     (b         64.0)
     (S         4.8)
     (tp        7.3)
     (r         7.5)
     (r1        3.0)
     (a         14.7)
     (Jx        350.0)
     (Sx        33.7)
     (Jy        27.9)
     (sokr t)
     (up  srtm0_tek)
     (St (С255 С285))
   )
   ( (nm "ДВТР_14")
     (H         140.0)
     (b         73.0)
     (S         4.9)
     (tp        7.5)
     (r         8.0)
     (r1        3.0)
     (a         17.4)
     (Jx        572.0)
     (Sx        46.8)
     (Jy        41.9)
     (sokr t)
     (up  srtm0_tek)
     (St (С255 С285 С345-3))
   )
Если кто-то отказывается считать приведенный фрагмент фрагментом базы прокатных двутавров, то я готов выслушать АРГУМЕНТИРОВАННЫЕ возражения по сути вопроса. Для тех, кто готов внимать далее приведу еще один фрагмент
(setq srtm0_tek
'(
  (up a_dwt0)
  (prf "ДВТР" srtm_pt "BZ/DWTR0.BZ")
;------------------------------------------------------------------------------
; В формулах для Jk и Wk коэф. 0.0000448 и 0.000448 приняты по источникам:
; - Справочник по теории упругости. под ред. П.М.Варвака и А.Ф.Рябова
;            изд. "Будивельник" Киев, 1971         стр.54
; - Стальные конструкции. Справочник конструктора. под ред. Н.П.Мельникова
;            Москва, Стройиздат, 1976              стр. 248-250
  (Jk  (progn (srtm_&) (* 0.0000448 (+ (* 2 b00 Tp00 Tp00 Tp00)
                                    (* (- h00 Tp00 Tp00) s00 s00 s00))))) ; см4
  (Wk  (progn (srtm_&) (* 0.000448  (/ (+ (* 2 b00 Tp00 Tp00 Tp00)
                              (* (- h00 Tp00 Tp00) s00 s00 s00)) Tp00)))) ; см4
;------------------------------------------------------------------------------
  (sl_i "SRTM(DWTRI)" srtm_pt)   ; Слайд для hlp
  (uklon 12.0)                   ; Уклон полки в процентах
  (nh '(p g ix iy Wx Wy Jk Wk uklon prf St typ_prf))
  (TU ("ГОСТ 8239-69" "Двутавры"))
  (St (С255 С285 С345-3 C345-4))
  (prt    5)            ; приоритет для спецификации
 )
)
я не убирал и не добавлял специально ни каких комментариев - все точно так, как это было при разработке SRTM-среды еще в 1991г. Слегка вспомнив двутавр и его основные характеристики, и дав определенную волю своей сообразительности, думаю, большинство из Вас сможет догадаться о назначении тех или иных ключей (хотя возможно и не всех) в этой БАЗЕ. И все же позволю себе дать некоторые комментарии. С полями H, b, S, tp, r, r1, a, Jx, Sx, Jy вроде бы все ясно - характеристики сечения почти по справочнику, nm - имя сечения в базе, sokr - признак сокращенного сортамента, St - список сталей из которых катался данный конкретный профиль (был в Союзе все же порядок хоть в чем-то). Наконец подошли к весьма интересному полю up - указатель наследования данных, именно благодаря этому ключу и наличию некоего "родительского" списка мы имеем возможность не помещать в каждую запись поля Jk, Wk и другие. Стоит обратить внимание, что и "родительский" список имеет свое поле up, обеспечивая, таким образом очередной уровень наследования. Как мне кажется, совершенно излишне говорить, что число уровней наследования практически не ограничено. Для того, чтобы оценить как много информации может быть вынесено на верхние уровни БАЗЫ приведем общий список для всех типов двутавров:
(setq a_dwt0
 '(
   (up  a_srtm)  ; Ссылка на общую информацию для всех баз SRTM-среды.
   (p   (progn (srtm_&) (* 0.001 (+ (* 2 h00)(* 4 b00) (* s00 -2.0)))))  ; м2/м
   (g   (progn (srtm_&) (* 0.785 A00)))                                  ; кг/м
   (ix  (progn (srtm_&) (sqrt (/ Jx00 A00))))                            ; см
   (iy  (progn (srtm_&) (sqrt (/ Jy00 A00))))                            ; см
   (Wx  (progn (srtm_&) (/ Jx00 (/ h00 20))))                            ; см3
   (Wy  (progn (srtm_&) (/ Jy00 (/ b00 20))))                            ; см3
   (Jk  (progn (srtm_&) (* 0.00004 (+ (* 2 b00 Tp00 Tp00 Tp00)
                                   (* (- h00 Tp00 Tp00) s00 s00 s00))))) ; см4
   (Wk  (progn (srtm_&) (* 0.0004  (/ (+ (* 2 b00 Tp00 Tp00 Tp00)
                            (* (- h00 Tp00 Tp00) s00 s00 s00)) Tp00))))  ; см4
   (nb0 (progn (srtm_&)   ; Базовые точки на поперечном сечении.
                  (list  nil
                        (list (* b00 0.5) (* h00 0.5) 0)
                        (list 0 (* h00 0.5) 0)
                         -2
                        (list (* b00 -0.5) (* h00 -0.5) 0)
                        (list 0 (* h00 -0.5) 0)
                         -5
   )))
   (bv_tek (progn       ; Описание боковых видов.
             (srtm_&)   ; Можно зеркалить относительно только вертикальной оси.
             (setq s00$  (if srtm_isk (srtm_isk s00  (* b00 0.15)) s00)
                   Tp00$ (if srtm_isk (srtm_isk Tp00 (* h00 0.20)) Tp00))
             (list
              (list
               (list srtm_ly8 (/ h00 2.0))
                ...
              (list
               (list srtm_ly8 (* 0.3535 (+ h00 b00 (- s00$))))
               (list srtm_ly8 (* 0.3535 (+ h00 (* Tp00$ -2) b00 (- s00$))))
                ...
              (list
               (list srtm_ly8 (/ b00 2.0))
                ...
               -2 1 2 3 -2
   )))
   (cr ("dwt0_cn.mns" "dwt0_cb.mns")          ; Списки меню для корректировок
       ("srtm(dwt0_cn)" "srtm(dwt0_cb)")      ; Слайды для списков меню
        srtm_pt)
   (m-f (srtm_dw t))                    ; Функция отрисовки
   (m-h (srtm_hl))                      ; hlp
   (symm 'xy)                           ; Двойная симметр
   (pnp  (progn (srtm_&)   ; Точки для напряжений прочности
            (list (list nil                              '(np ts)   )
                  (list (list  0  (- (/ h00 2) Tp00) 0)  '(np ts tk))
                  (list (list (* b00 0.5) (* h00 0.5) 0) '(np )     )
            )))
   (sort 6)               ; балки и швеллеры
   (nm_spf (setq p00 (cadr (assoc 'nm select_list)) 
                 p00 (strcat "Двт " (substr p00 6))))   
           ; альтернативный текст для спецификации
   (typ_prf "DWT")
   (xy_$dw1 (progn (srtm_&) (list  0 (* 0.5 s00)))) ;смещение для симм двутавра
   (xy_$dw2 (progn (srtm_&) (list  0 (* 0.5 s00)))) ;смещение для несимм двутавра
   (xy_$tw1 (progn (srtm_&) (list  0 (* 0.5 s00)))) ;смещение для тавров
 )
)
Еще один интересный момент состоит в использовании вычисляемых полей, вы заметили что некоторые поля содержат список вида (progn ...) - это они и есть. Не стану слишком много распространяться о том, сколь мощное орудие - вычисляемые поля, тот кто умеет анализировать сам в состоянии оценить эту возможность.
 
  Совершенно очевидно, что для использования тех возможностей которых мы коснулись в данной статье необходим соответствующий набор функций. Ждите... Об этом будет чуть позже.