ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Тулза для работы с исходниками БД
15 сообщений из 15, страница 1 из 1
Тулза для работы с исходниками БД
    #38158033
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Максим Н
Участник
Много говорится о бестпрактис хранения исходников БД в СКВ, причем каждый объект - это отдельный файл и т.д.

Так же есть множество модных (и не очень) деплойеров и changhe manager'ов, которые позволяют управлять изменениями кода БД, собирать дифф-скрипты, накатывать на базы и контроллировать все это дело (Liquibase, dbdeploy, etc).

А есть какая-либо тулза, которая помогала бы непосредственно управлять самим исходным кодом , например:
- Могла набросать каркас из папок и файлов для хранения исходных кодов объектов;
- собрать из этих исходников итоговый скрипт, который можно юзать в какой-нибудь CI. Причем сборка с различными параметрами, например частичная (отдельной таблицы или нескольких таблиц), без ФК, ПК, индексов и т.д. Сборка с тестовыми данными, сборка с боевыми данными и многое другое...
- контроллировать актуальность хранимых объектов, т.е. следить за тем, что если был удален пользователь, то и все его объекты так же должны пропасть из текущей версии. Если грохнули таблицу, то также удалились ее индексы (которые так же хранятся в отдельных файлах и имеют свою историю изменения).

?
...
Рейтинг: 0 / 0
19.02.2013, 20:34
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38323334
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Максим Н
Участник
Это снова я... Не получив ответа, решил накидать прототип - https://github.com/mgramin/LiWIDE

Данная тулзовина предназначена для организации хранения исходного кода создания БД (DDL, DML etc).
В частности была навеяна постом ( http://www.sql.ru/forum/927233/ishodnyy-kod-obktov-bd) и статьей, из него родившейся.

Будет интересно узнать отзывы и мнения, здоровая (и не очень) критика приветствуется.

Тулза позволяет описать структуру типов объектов БД в формате xml и дальше работать с их экземплярами.
Если выполнить
Код: powershell
1.
$ lwd -i


то можно получить несколько преднастроенных типов объектов.

Например: simple_table.xml, описывает обычную таблицу, элементы которой (ddl, indexes, test_data), хранятся в разных файлах:
 

Код: xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DBObjType>
    <DBObjChildList>
        <content></content>
        <file>${objName}_table.sql</file>
        <folder></folder>
        <mask>CREATE.TABLE.${objName}.*?;</mask>
        <name>ddl</name>
        <priority>0</priority>
        <shortName>d</shortName>
        <snippetText>CREATE TABLE ${objName} (id INTEGER);</snippetText>
        <startText></startText>
        <stopText></stopText>
    </DBObjChildList>
    <DBObjChildList>
        <content></content>
        <file>${objName}_table.sql</file>
        <folder></folder>
        <mask>CREATE.INDEX.[a-zA-Z0-9_]{1,32}.?(ON).*?(${objName}).*?;</mask>
        <name>indexes</name>
        <priority>0</priority>
        <shortName>i</shortName>
        <snippetText>CREATE INDEX ${objName}_idx ON TABLE ${objName};</snippetText>
        <startText></startText>
        <stopText></stopText>
    </DBObjChildList>
    <DBObjChildList>
        <content></content>
        <file>${objName}_table.sql</file>
        <folder></folder>
        <mask></mask>
        <name>test_data</name>
        <priority>0</priority>
        <shortName>td</shortName>
        <snippetText>INSERT INTO ${objName} VALUES ...;</snippetText>
        <startText>--##### START TEST DATA DML FOR ${objName} TABLE #####--</startText>
        <stopText>--#####STOP TEST DATA DML FOR ${objName} TABLE #####--</stopText>
    </DBObjChildList>
    <description>One table in one file</description>
    <file>${objName}_table.sql</file>
    <folder></folder>
    <name>${objName}</name>
    <path></path>
    <shortName>stab</shortName>
    <typeName>simple_table</typeName>
</DBObjType>




Так же есть другие типы объектов.
Код: powershell
1.
2.
3.
4.
5.
6.
$ ls ./.lwd/
	all_table_in_one_file.xml
	package.xml
	simple_table_patch.xml
	simple_table.xml
	table.xml


Ну и никто не ограничивает создание своих собственных типов объектов.

Теперь создадим несколько табличек:
Код: powershell
1.
$ lwd add -t table -n SALARY JOBS MANAGERS CUSTOMERS -p simple_tables


В ответ получим:
 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
--simple_tables/SALARY_tbl/SALARY_ddl.sql

  CREATE TABLE SALARY (id INTEGER);



--simple_tables/SALARY_tbl/indexes/indexes.sql
-- ##### start index ddl #####
  CREATE INDEX SALARY_idx ON TABLE SALARY;
-- ##### stop index ddl #####


--simple_tables/SALARY_tbl/test_data/data.sql
-- ##### start test data #####
  INSERT INTO SALARY.....
-- ##### stop test data #####



--simple_tables/JOBS_tbl/JOBS_ddl.sql

  CREATE TABLE JOBS (id INTEGER);



--simple_tables/JOBS_tbl/indexes/indexes.sql
-- ##### start index ddl #####
  CREATE INDEX JOBS_idx ON TABLE JOBS;
-- ##### stop index ddl #####


--simple_tables/JOBS_tbl/test_data/data.sql
-- ##### start test data #####
  INSERT INTO JOBS.....
-- ##### stop test data #####



--simple_tables/MANAGERS_tbl/MANAGERS_ddl.sql

  CREATE TABLE MANAGERS (id INTEGER);



--simple_tables/MANAGERS_tbl/indexes/indexes.sql
-- ##### start index ddl #####
  CREATE INDEX MANAGERS_idx ON TABLE MANAGERS;
-- ##### stop index ddl #####


--simple_tables/MANAGERS_tbl/test_data/data.sql
-- ##### start test data #####
  INSERT INTO MANAGERS.....
-- ##### stop test data #####



--simple_tables/CUSTOMERS_tbl/CUSTOMERS_ddl.sql

  CREATE TABLE CUSTOMERS (id INTEGER);



--simple_tables/CUSTOMERS_tbl/indexes/indexes.sql
-- ##### start index ddl #####
  CREATE INDEX CUSTOMERS_idx ON TABLE CUSTOMERS;
-- ##### stop index ddl #####


--simple_tables/CUSTOMERS_tbl/test_data/data.sql
-- ##### start test data #####
  INSERT INTO CUSTOMERS.....
-- ##### stop test data #####




Предудущую команду можно переписать так, чтобы в ответ получить только имена созданных файлов, для этого заюзаем шаблон вывода "conf/templates/only_name_tmpl.ftl",
вместо шаблона, который используется по умолчанию ("conf/templates/default.ftl"):

Код: powershell
1.
$ lwd add -t table -n SALARY JOBS MANAGERS CUSTOMERS -p simple_tables -tl n



Это может пригодится для того чтобы заюзать например с текстовым редактором, и сразу получить созданные файлики на редактирование, как то так:

Код: powershell
1.
$ vim -o `lwd add -t table -n SALARY JOBS MANAGERS CUSTOMERS -p simple_tables -tl n`




В итоге получим 4 папки такой структуры, где каждый жлемент каждой таблицы хранится в отдельном файле:
 

Код: powershell
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
$ tree
	--- CUSTOMERS_tbl
	|   |-- CUSTOMERS_ddl.sql
	|   |-- indexes
	|   |   |- indexes.sql
	|   |-- test_data
	|       |-- data.sql
	|-- JOBS_tbl
	|   |-- indexes
	|   |   |-- indexes.sql
	|   |-- JOBS_ddl.sql
	|   |-- test_data
	|       |-- data.sql
	|-- MANAGERS_tbl
	|   |-- indexes
	|   |   |-- indexes.sql
	|   |-- MANAGERS_ddl.sql
	|   |-- test_data
	|       |-- data.sql
	|-- SALARY_tbl
	    |-- indexes
	    |   |-- indexes.sql
	    |-- SALARY_ddl.sql
	    |-- test_data
		|-- data.sql




Теперь со всем эим можно поработать.
Например получить скрипт на создание тестовых данных для всех таблиц:

Код: powershell
1.
lwd get -t table -n SALARY JOBS MANAGERS CUSTOMERS -e test_data -p simple_tables



 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
--simple_tables/SALARY_tbl/test_data/data.sql
-- ##### start test data #####
  INSERT INTO SALARY.....
-- ##### stop test data #####


--simple_tables/JOBS_tbl/test_data/data.sql
-- ##### start test data #####
  INSERT INTO JOBS.....
-- ##### stop test data #####


--simple_tables/MANAGERS_tbl/test_data/data.sql
-- ##### start test data #####
  INSERT INTO MANAGERS.....
-- ##### stop test data #####


--simple_tables/CUSTOMERS_tbl/test_data/data.sql
-- ##### start test data #####
  INSERT INTO CUSTOMERS.....
-- ##### stop test data #####




Или отредактировать эти файлы:
Код: powershell
1.
$ vim -o `lwd get -t table -n SALARY JOBS MANAGERS CUSTOMERS -e test_data -p simple_tables -tl n`



Весь скрипт для таблицы SALARY:


$ lwd get -t table -n SALARY -p simple_tables

 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
--simple_tables/SALARY_tbl/SALARY_ddl.sql
CREATE TABLE SALARY (id INTEGER);

--simple_tables/SALARY_tbl/indexes/indexes.sql
-- ##### start index ddl #####
  CREATE INDEX SALARY_idx ON TABLE SALARY;
-- ##### stop index ddl #####

--simple_tables/SALARY_tbl/test_data/data.sql
-- ##### start test data #####
  INSERT INTO SALARY.....
-- ##### stop test data #####




и т.д.
При этом есть возможность создать собственные шаблоны для вывода (соотвествующий внутрикомандным стандартам например).

Так же, те же самые таблицы можно организовать в любую другую струкутур, например каждая таблица в отдельном файле:
Код: powershell
1.
$ lwd add -t simple_table -n SALARY JOBS MANAGERS CUSTOMERS -p simple_tables_1



Посмотрим, что получилось:
Код: powershell
1.
$ lwd get -t simple_table -n SALARY JOBS MANAGERS CUSTOMERS -p simple_tables_1 -tl n



 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
simple_tables_1/SALARY_table.sql
simple_tables_1/SALARY_table.sql
simple_tables_1/SALARY_table.sql

simple_tables_1/JOBS_table.sql
simple_tables_1/JOBS_table.sql
simple_tables_1/JOBS_table.sql

simple_tables_1/MANAGERS_table.sql
simple_tables_1/MANAGERS_table.sql
simple_tables_1/MANAGERS_table.sql

simple_tables_1/CUSTOMERS_table.sql
simple_tables_1/CUSTOMERS_table.sql
simple_tables_1/CUSTOMERS_table.sql




Одну таблицу рассмотрим поближе:

Код: powershell
1.
$ lwd get -t simple_table -n JOBS -p simple_tables_1



 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
--simple_tables_1/JOBS_table.sql
CREATE TABLE JOBS (id INTEGER);

--simple_tables_1/JOBS_table.sql
CREATE INDEX JOBS_idx ON TABLE JOBS;

--simple_tables_1/JOBS_table.sql
--##### START TEST DATA DML FOR JOBS TABLE #####--
INSERT INTO JOBS VALUES ...;
--#####STOP TEST DATA DML FOR JOBS TABLE #####--




Получили такой же результат, как и в первом случае, при хранении в отдельных файлах.
Т.е. можем сформировать любой скрипт, в не зависимости от того как исходные скрипты хранятся на диске.


Ну и обмолвлюсь о возможности хранить все таблицы (или другие типы объектов) в одном файле, как в дампе:
Код: powershell
1.
$ lwd add -t all_table_in_one_file  -n SALARY JOBS MANAGERS CUSTOMERS -p one_file_tables



В итоге получим одни файл tables.sql, но это не помешает нам формировать любые скрипты как в 1-м и 2-м случае.


Теперь пришло время поговорить о патчах. Т.к. данная тулзовина не является DB-мигратором, то она может только подготовить патч для объекта(объектов), в том числе и для дальнейшего его использования в миграторах (пример с liquibase дальше).
Для этого используем заранее подготовленный тип объекта simple_table_patch (из файлика .lwd/simple_table_patch.xml):
Код: powershell
1.
$ lwd add_patch -t simple_table_patch -n SALARY -v 1.1 -p simple_tables



Можем создать и сразу заполнить сразу несколько патчей для объекта:
Код: powershell
1.
$ vim -o `lwd add_patch -t simple_table_patch -n SALARY -v 1.2 1.3 -p simple_tables -tl n`



Или патч с правками для нескольких объектов:
Код: powershell
1.
$ vim -o `lwd add_patch -t simple_table_patch -n SALARY MANAGERS -v 1.5 -p simple_tables -tl n`



А так же просмотреть историю изменения объекта по птчам, например так:
Код: powershell
1.
$ lwd get_patch -t simple_table_patch -n SALARY -v 1.2 1.3 1.5 -p simple_tables



В итоге увидим, что рпоисходило с ним в 3-х патчах и так же увидеть его текущее состояние (или исходное, это уже зависит как организован код в вашем проекте):
Код: powershell
1.
$ lwd get -t simple_table -n SALARY -p simple_tables_1



Ну выглядеть наши патчи в ФС будут примерно так:

 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
$ tree

	|-- 1.2
	|   |-- SALARY_table.sql
	|-- 1.3
	|   |-- SALARY_table.sql
	|-- 1.5
	    |-- MANAGERS_table.sql
	    |-- SALARY_table.sql




Теперь обещанный Ликвибэйс.
Делаем новый шаблон для отображения скриптов, очень похожий на родной ликвибесовский чейнджлог, conf/tenplates/lb_change_log.ftl,
и по аналогии описываем его в config.xml:

 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
   xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
   http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd">
  <#list results.getAll() as result>
     <changeSet id="1" author="">
      <sql> 
        ${result.getFileText()}
      </sql>
    </changeSet>
  </#list>
</databaseChangeLog>




Тепер делаем очередной патч, но с применением этого шаблона:
Код: powershell
1.
$ lwd add_patch -t simple_table_patch -n SALARY -v 2.1 -p simple_tables -tl l



Получим xml-ку (пока страдает форматирование (кода отступы используются), и не подставляется номер версии, в ближайших версиях сделаю):
 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
<?xml version="1.0" encoding="UTF-8"?>

<databaseChangeLog
   xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
   http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-2.0.xsd">

       <changeSet id="1" author="">
      <sql> 
        --### alter ddl for SALARY ###
ALTER TABLE SALARY ...
--### end alter ddl for SALARY ###

      </sql>
    </changeSet>
 
</databaseChangeLog>





Наверное сумбурно получилось...
Если будут вопросы, то с удовольствием отвечу.
...
Рейтинг: 0 / 0
07.07.2013, 20:49
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38323488
deblogger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
deblogger
Участник
Максим Н,

Типа расширение XSL, типа XSLBD :)

Кстати, а комментарии таблиц/полей разве нельзя хранить в поле COMMENT? Просто по ссылке на статью проиллюстрирована потеря комментариев, все остальное на месте.

Тот факт что БД живут в БД освящает одна из заповедей Кодда: факт должен храниться в одном месте.
...
Рейтинг: 0 / 0
08.07.2013, 00:09
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38323958
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Максим Н
Участник
deblogger,

Комментарии это только одна из проблем.
Про Кодда аргумент мощный, но на практике бывает удобно хранить исходный код создания(изменения) базы именно в файлах под контролем СКВ. Это дает несколько плюсов:
- модульность (т.е. объекты можно разбить тематически, это Ядро, это Кадры, это ЗП и т.д.),
- возможность вести несколько версий баз(веток) (основной код(базвый, одинаковый везде), код базы для разработки, для тестов, для нагрузочных тестов, для продакшенов, которые тоже могут отличаться),
- безболезненная параллельная работа над одним объектом нескольких разработчиков (используя средства СКВ, бранчинг, слияние и все такое)
- возможность все это дело заскриптовать нужным образом, организовать билды (ночные и не очень) для разных версий, или например собрать скрипт для создания(обновления) нужной базы;
- вести патчи
- возможность описать и хранить любом виде не только стандартные объекты БД (таблицы, представление, хранимая процедура etc), но и свои собственные (например параметры системы, различные регистрации объектов и пр.).
- и т.д..

Мы тут с ребятами из соседней ветки общались на эту тему немножко - http://www.sql.ru/forum/1019474/vybor-subd-dlya-nebolshoy-java-utility

В итоге я попробовал накидать инструмент, который мог бы автоматизировать процесс создания и управления этим кодом.
Можно описать объект базы данных в нужном виде (а не только в том, в котором представляет его IDE) в формате XML(пока), а затем создавать его экземпляры. Дальше на основании этого описания можно делать различные сборки и манипуляции с данными объектами.
Т.е. некая попытка организовать хранение кода БД именно в файлах, а БД использовать как компилятор.
...
Рейтинг: 0 / 0
08.07.2013, 12:54
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38324965
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
Максим НТ.е. некая попытка организовать хранение кода БД именно в файлах, а БД использовать как компилятор.

По моему это не правильный подход к работе с БД.
Это мне напоминает времена DOS, когда некоторые товарищи в каталогах файл-помойки вели файлик index.txt.
В котором содержалась вся информация о файлах в каталоге.
При этом приобретая проблема поддержки данного файла в актуальном состоянии.
В конце концов он просто становился копией команды dir :-)

Т.е. в конце концов вы придете к тому, что придется реализовывать все что есть в SQL-сервере, только без SQL-сервера.

Насчет "хранения" информации о БД.
Самым оптимальным является хранение ERD-диаграмм. ;-)
...
Рейтинг: 0 / 0
09.07.2013, 07:25
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38325383
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
mad_nazgulНасчет "хранения" информации о БД.
Самым оптимальным является хранение ERD-диаграмм. ;-)
По структуре таблиц да. По хранению описаний функций и ХП - нет.
...
Рейтинг: 0 / 0
09.07.2013, 12:50
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38325417
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Максим Н
Участник
mad_nazgulПо моему это не правильный подход к работе с БД.

Возможно. Но у варианта создавать и хранить все объекты в базе на живую, тоже есть свои недостатки:
во первых, код криво выгружается (потом на форуме куча вопросов всплывает: "как выгрузить код таблицы без этого", "как выгрузить с этим",
"Как добавить именно такие гранты для объекта в выгрузку"), ну а потом каждая ИДЕ(тулза) выгружает и отображает код как ей вздумается,
аккуратно выковыривая его из систменых таблиц (или еще откуда). И все этого вместо того чтобы просто хранить код создания объектов
в нужном виде в нужном месте, ну а затем собирать из него чего надо.
Если не прав то поправьте пожалуйста. Ну еще плюс параллельная работа, ведение нескольких веток, хранение собственных типов объектов,
разделение на модули и многое другое.

С ER диаграммами тоже не все радужно.
Извините за боянистый пример, но все же: голое описание синтаксиса команды CREATE TABLE в официальной оракловой документации занимает
несколько десятков страниц. Как всем этим можно воспользоваться при визуальном дизайне табличек я не очень себе представляю. Это уже не говоря
о тэйблспейсах, датафайлах, партицировании и пр.
Еще часто при разработке БД объекты не создают обычными CREATE или ALTER напрямую, а через какие-нибудь процедуры-обертки, которые например
выполняют какую либо регистрацию или/и выполняют дополнительные действия в зависимости от выполняемой среды. Ну и логично хранить код
вызова этих процедур, как код создания объектов.
...
Рейтинг: 0 / 0
09.07.2013, 13:08
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38325562
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Максим Н...
С ER диаграммами тоже не все радужно.
...
Открой для себя PowerDesigner
...
Рейтинг: 0 / 0
09.07.2013, 14:49
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38325652
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Максим Н
Участник
Infernal V. Raven,

Открывал. А еще AllFusion ERwin Data Modeler и т.д.
Штука крутая, но не панацея.
Платный, большой, громоздкий, ну и как бы немного для других целей.

Эта тулзовина может пригодится когда разработка БД идет именно от исходников, которые версионируются, собираются в разные версии (разработка, тестовая, продакшн etc) собираются ночные билды и т.д.
...
Рейтинг: 0 / 0
09.07.2013, 15:31
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38325672
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Максим НОткрывал. А еще AllFusion ERwin Data Modeler и т.д.
Штука крутая, но не панацея.
Платный, большой, громоздкий, ну и как бы немного для других целей.
Как-то не вяжется с:
Максим Нголое описание синтаксиса команды CREATE TABLE в официальной оракловой документации занимает
несколько десятков страниц. Как всем этим можно воспользоваться при визуальном дизайне табличек я не очень себе представляю. Это уже не говоря
о тэйблспейсах, датафайлах, партицировании и пр.
Еще часто при разработке БД объекты не создают обычными CREATE или ALTER напрямую, а через какие-нибудь процедуры-обертки, которые например
выполняют какую либо регистрацию или/и выполняют дополнительные действия в зависимости от выполняемой среды. Ну и логично хранить код
вызова этих процедур, как код создания объектов.
...
Рейтинг: 0 / 0
09.07.2013, 15:43
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38325898
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Максим Н
Участник
Infernal V. RavenМаксим НОткрывал. А еще AllFusion ERwin Data Modeler и т.д.
Штука крутая, но не панацея.
Платный, большой, громоздкий, ну и как бы немного для других целей.
Как-то не вяжется с:
Максим Нголое описание синтаксиса команды CREATE TABLE в официальной оракловой документации занимает
несколько десятков страниц. Как всем этим можно воспользоваться при визуальном дизайне табличек я не очень себе представляю. Это уже не говоря
о тэйблспейсах, датафайлах, партицировании и пр.
Еще часто при разработке БД объекты не создают обычными CREATE или ALTER напрямую, а через какие-нибудь процедуры-обертки, которые например
выполняют какую либо регистрацию или/и выполняют дополнительные действия в зависимости от выполняемой среды. Ну и логично хранить код
вызова этих процедур, как код создания объектов.

Почему же, с одной стороны визуальная разработка (дизайнеры, визуальные ИДЕ, выгрузка дампов, генерация дифов, миграции и т.д.) с другой стороны "программирование" БД, работа с исходным кодом (сборка версий, патчи). То и то довольно часто используется, возможно и комбинирование.
...
Рейтинг: 0 / 0
09.07.2013, 17:27
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38325931
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Максим НInfernal V. Ravenпропущено...
Как-то не вяжется с:
пропущено...


Почему же, с одной стороны визуальная разработка (дизайнеры, визуальные ИДЕ, выгрузка дампов, генерация дифов, миграции и т.д.) с другой стороны "программирование" БД, работа с исходным кодом (сборка версий, патчи). То и то довольно часто используется, возможно и комбинирование.
брр...
Сперва разберемся с этим:
голое описание синтаксиса команды CREATE TABLE в официальной оракловой документации занимает
несколько десятков страниц. - документация обычно занимает много страниц.
Как всем этим можно воспользоваться при визуальном дизайне табличек я не очень себе представляю - в средствах моделирования (например PD) как-раз это очень хорошо представляется.
Это уже не говоря о тэйблспейсах, датафайлах, партицировании и пр. - также представлено в PD
Еще часто при разработке БД объекты не создают обычными CREATE или ALTER напрямую, а через какие-нибудь процедуры-обертки, которые например
выполняют какую либо регистрацию или/и выполняют дополнительные действия в зависимости от выполняемой среды. - можно примеры? Дополнить скрипт создания таблицы своими скриптами (например для обновления метаданных ИС) в PD можно с помощью настроек.
Ну и логично хранить код
вызова этих процедур, как код создания объектов. - можно. Но для меня, например, версионировать модель предпочтительнее, по сравнению с кодом который ее создает.
...
Рейтинг: 0 / 0
09.07.2013, 17:41
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38326074
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Максим Н
Участник
Infernal V. Ravenголое описание синтаксиса команды CREATE TABLE в официальной оракловой документации занимает
несколько десятков страниц. - документация обычно занимает много страниц.
Я про то, что такая операция как создание таблицы содержит очень много опций (параметров) и размазать это все по визуальной форме-конструктору, а потом еще в этом ориентироваться довольно проблематично. А потом приходится обучаться работе именно с этой средой, а не с конкретной СУБД.

Infernal V. RavenЕще часто при разработке БД объекты не создают обычными CREATE или ALTER напрямую, а через какие-нибудь процедуры-обертки, которые например
выполняют какую либо регистрацию или/и выполняют дополнительные действия в зависимости от выполняемой среды. - можно примеры?

Например при создании каждой таблицы ее нужно зарегистрировать в системе, в зависимости от ее предназначения (на одной из моих работ это было нужно для заюзывании ее в системе репликации). Регистрация представляла собой вызов спец процедуры с параметрам таблицы.
В другом проекте через обертку создавались пользовательские джобы, т.к. количество их очень большое, и требовался дополнительный контроль, в зависимсоти от модуля, от автора джоба, от времени запуска, единый способ создания и стиль оформления. В процедуре используются входные параметры обычного DBMS_JOB.isubmit + еще дополнительные, необходимые для приложения. Где то здесь на форуме (ссылку наврядли найду) парень писал, что у них все объекты (или почти все) создавались через похожие обертки, а прав на создание объектов на прямую (ALTER, CREATE) у разраюотчиков вообще не было. Вобщем практика весьма распротраненная.

Infernal V. RavenНу и логично хранить код
вызова этих процедур, как код создания объектов. - можно. Но для меня, например, версионировать модель предпочтительнее, по сравнению с кодом который ее создает.

А я и не говорю, что это у меня серебряная пуля. Для меня самого это пока больше как эксперимент, и интересно что из этого может получиться.
Лично для меня, чтобы создать табличку, гораздо проще просто открыть файл (или создать новый) наваять там оператор (операторы, при чем в этом файле уже может быть готовый снипет, офрмленный по стандратам проекта, или даже отдельного модуля), закинуть в скрипт для дальнейшего сбора патча и заверсионировать.
Ну еще такие дела лихо скриптуются. Например ставим в планировщик задание, которое будет каждую ночь пересобирать рабочую базу и еще плюс собирать тестовую базу с тестовыми данными, которой можно будет пользоваться в течении следующего дня.
...
Рейтинг: 0 / 0
09.07.2013, 20:27
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38328171
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
Максим НЯ про то, что такая операция как создание таблицы содержит очень много опций (параметров) и размазать это все по визуальной форме-конструктору, а потом еще в этом ориентироваться довольно проблематично. А потом приходится обучаться работе именно с этой средой, а не с конкретной СУБД.

Какая-то каша.
Для манипуляции объектами есть подмножество SQL - DML. Есть визуальные средства работы с ним - приводившиеся PD, ErWin и другие, например, встроенные в платформу либо программу. Притом они позволяют централизовано хранить описание модели.
Для хранения отдельных скриптов можно использовать базу данных, файловую систему либо другое хранилище. Плюс системы версионирования.

Максим ННапример при создании каждой таблицы ее нужно зарегистрировать в системе, в зависимости от ее предназначения (на одной из моих работ это было нужно для заюзывании ее в системе репликации). Регистрация представляла собой вызов спец процедуры с параметрам таблицы.

PD позволяет автоматизировать создание скриптов и создавать дополнительные "обвесы" для событий создания, удаления объектов

Максим Нчерез похожие обертки, а прав на создание объектов на прямую (ALTER, CREATE) у разраюотчиков вообще не было. Вобщем практика весьма распротраненная.
Хрень какая-то. Разрешений на CREATE, ALTER нет, но создавать объекты можно, только через дымоход. Можно ссылки на описание того, где подобные решения используются?
Похожую систему одну знаю - 1С, но она как раз с точки зрения работы с СУБД - сущий ад.

Максим НЛично для меня, чтобы создать табличку, гораздо проще просто открыть файл (или создать новый) наваять там оператор (операторы, при чем в этом файле уже может быть готовый снипет, офрмленный по стандратам проекта, или даже отдельного модуля), закинуть в скрипт для дальнейшего сбора патча и заверсионировать.
Ну еще такие дела лихо скриптуются. Например ставим в планировщик задание, которое будет каждую ночь пересобирать рабочую базу и еще плюс собирать тестовую базу с тестовыми данными, которой можно будет пользоваться в течении следующего дня.
Ну так это никак и не мешает хранению модели в PD и генерации скриптов. Для достаточно больших проектов актуализация ER-диаграмм является обязательным. А накат патчей, сборки и т.д. еще более актуальны чем для мелких проектов, в которых разработка идет "от исходников".
Насчет ценности утилиты есть сомнения, хотя я и не говорю, что она хреновая. Возможно кому-нибудь пригодится.
...
Рейтинг: 0 / 0
11.07.2013, 14:30
| Ответить | Цитировать | Написать  
Тулза для работы с исходниками БД
    #38333500
Максим Н
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Максим Н
Участник
Infernal V. RavenКакая-то каша.
Для манипуляции объектами есть подмножество SQL - DML...
...Для хранения отдельных скриптов можно использовать базу данных, файловую систему либо другое хранилище. Плюс системы версионирования.
Именно, я и говорю о хранении скриптов (и совершенно не важно как они получены, сгенерены дизайнером, IDE'шкой, выгружены из другой базы или бережно написаны руками) в файловой системе под СКВ. Вопрос в том чтобы организовать это хранение: здесь объекты модуля такого то, здесь такого то, таблицы хранятся в таком-то виде, процедуры в таком-то. Но когда объектов и типов объектов много, когда работает более менее большая команда разработчиков, могут возникнуть проблемы с поиском нужных файлов со скриптами, со сбором версий, патчей и т.д. Вот и возникла идея двухколесного стального коня, который помог бы грубо говоря, шаблонизировать исходники БД, хранящиеся в файловой системе. Чтобы можно было хранить объекты (и вести контроль за этим) именно в таком виде в каком удобно (например весь DDL таблицы в одном файле, или наоборот, скрипт создания, индексы, ключи etc в разных файлах), а не в том в котором навязывает IDE. А потом чтобы можно было достать нужные элементы нужных типов, например "достать индексы всех таблиц модуля ЗП", "собрать скрипт с грантами для всех процедур модулей Кадры и Налоги". Чтобы можно было объявить и работать с собственными типами объектов.

Infernal V. RavenХрень какая-то. Разрешений на CREATE, ALTER нет, но создавать объекты можно, только через дымоход. Можно ссылки на описание того, где подобные решения используются?

Ссылку пока не нашел, давно это было...


Infernal V. RavenНу так это никак и не мешает хранению модели в PD и генерации скриптов. Для достаточно больших проектов актуализация ER-диаграмм является обязательным. А накат патчей, сборки и т.д. еще более актуальны чем для мелких проектов, в которых разработка идет "от исходников".
Насчет ценности утилиты есть сомнения, хотя я и не говорю, что она хреновая. Возможно кому-нибудь пригодится.

Как минимум PD не получится нормально заскриптовать (или я не прав?), что бы например по крону у меня автоматом собиралась база (причем как упоминал разных видов и для разных целей, по кускам или полностью), или рефрешились какие-нибудь тестовые данные или справочники на тестовых серверах и т.д.
Ну и вообще это разного поля ягоды.
...
Рейтинг: 0 / 0
16.07.2013, 22:56
| Ответить | Цитировать | Написать  
15 сообщений из 15, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Тулза для работы с исходниками БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=38325383&tid=1541173]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 154ms
get topic data:
 10ms
get forum data:
 3ms
get page messages:
 54ms
get tp. blocked users:
 1ms
others: 14ms
total:  266ms
созд. / загр.: 266ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]