powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Эффективность разработки ПО
25 сообщений из 127, страница 3 из 6
Эффективность разработки ПО
    #38174285
Inkelyad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
U-gene2 sphinx_mv
Ну Вы хоть в Википедии посмотрите, что такое аксиома, или вспомните, с чего геометрию начинали изучать (с аксиоматических понятий "точка" и "прямая"). А тоВы лепите, не думая, а впечатление, чтоВы не думаете.
В статьях по ссылкам был же ответ.

Готовая математическа конструкция (доказательство теоремы/правильности алгоритма/описания способа вычислений) базируется/cтроится на утверждениях, называемых аксиомами.

Но придумывание/конструирование этой конструкции не с аксиом начинают.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174344
Фотография Amberit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old Nick,

авторИ мне кажется мы разные вещи понимаем под словами ООП в базе

Наверное, в этом и загвоздка. По-моему, Вы недостаточно четко разъяснили, что имеете в виду под "ООП в базе", и у большинства камрадов это вызвало "легкое" недоумение...

В ORACLE (не знаю как в других БД, в них я не копенгаген) ООП на уровне SQL, PL/SQL - это, мягко говоря, нужно как козе баян. Конечно, некоторые возможности есть, и их даже можно/нужно использовать в определенных случаях, но почти всегда их можно безболезненно заменить на процедурный подход (в PL/SQL) или переделать в реляционную модель (SQL). Такой подход почти всегда (за редкими исключениями) более понятен, сопровождаем, имеет лучшую производительность. Ведь реализация БД появилась в те времена, когда об ООП в лучшем случае писались какие-то научные исследования, и естественно ядро БД изначально не поддерживает таких возможностей, это "не родное" для всех БД с многолетней историей...

Все-таки, мое ИМХО, нужно разделять подходы к разработке внутри БД и на Java, C# и т.д. Внутри БД нужно использовать те механизмы, которые наиболее оптимальны и проверены временем, а не изобретать велосипеды для реализации стандартных задач.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174467
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AmberitOld Nick,

авторИ мне кажется мы разные вещи понимаем под словами ООП в базе

Наверное, в этом и загвоздка. По-моему, Вы недостаточно четко разъяснили, что имеете в виду под "ООП в базе", и у большинства камрадов это вызвало "легкое" недоумение...

В ORACLE (не знаю как в других БД, в них я не копенгаген) ООП на уровне SQL, PL/SQL - это, мягко говоря, нужно как козе баян. Конечно, некоторые возможности есть, и их даже можно/нужно использовать в определенных случаях, но почти всегда их можно безболезненно заменить на процедурный подход (в PL/SQL) или переделать в реляционную модель (SQL). Такой подход почти всегда (за редкими исключениями) более понятен, сопровождаем, имеет лучшую производительность. Ведь реализация БД появилась в те времена, когда об ООП в лучшем случае писались какие-то научные исследования, и естественно ядро БД изначально не поддерживает таких возможностей, это "не родное" для всех БД с многолетней историей...

Все-таки, мое ИМХО, нужно разделять подходы к разработке внутри БД и на Java, C# и т.д. Внутри БД нужно использовать те механизмы, которые наиболее оптимальны и проверены временем, а не изобретать велосипеды для реализации стандартных задач.

Оно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака.

Просто вы не умеете его готовить (с) не моё
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174471
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 sphinx_mv, kmaw ,Inkelyad

Повторю цитату
"Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома."

Ну если бы был глагол "подбирается" или "придумывается", то я бы не возражал. А говорить, что аксиомы 1)откуда-то 2)выводятся - бред. Имею право это отметить. И все толкования и объяснения здесь - это как сначала сказать, что "Волга вытекает из Каспийского моля" а потом начать оправдываться, что де она впадает , конечно.

2 sphinx_mv, espacially
Я про ООП ни слова не сказал. По мне, так удобнее чем предыдущие структуры и функции. А аргумент про количество классов в поставке меня вообще удивляет. Например, я не перечитал всех книг, и вряд ли перечитаю. И никто не знает, сколько их есть. Но это не значит , что они вообще не нужны.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174522
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sphinx_mviscrafmпропущено...

плакать или смеяться? Автор может быть хоть котом в сапогах, но это не повод ляпать о том, что в бухгалтерии нет наследования.Нет в бухгалтерии наследования - и никогда не было!
а выше приведенный пример не читали? Ладно, послушаем опытного бухгалтера, нет так нет. Ты автор этой статьи что-ли?
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174529
Фотография ЕвгенийВ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вообще ООП+женерики+лямбды и прочие деревья выражений - большая сила, нужно только понимать что к чему и уметь использовать.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174534
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакНо появление в команде еще и болтунов-дармоедов в виде ... архитектора не принесет улучшений:) Это я по опыту говорю.
поздравляю с "шикарнейшим" опытом. Только почему здесь так принято гордится этим.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174549
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old NickAmberitOld Nick,

пропущено...


Наверное, в этом и загвоздка. По-моему, Вы недостаточно четко разъяснили, что имеете в виду под "ООП в базе", и у большинства камрадов это вызвало "легкое" недоумение...

В ORACLE (не знаю как в других БД, в них я не копенгаген) ООП на уровне SQL, PL/SQL - это, мягко говоря, нужно как козе баян. Конечно, некоторые возможности есть, и их даже можно/нужно использовать в определенных случаях, но почти всегда их можно безболезненно заменить на процедурный подход (в PL/SQL) или переделать в реляционную модель (SQL). Такой подход почти всегда (за редкими исключениями) более понятен, сопровождаем, имеет лучшую производительность. Ведь реализация БД появилась в те времена, когда об ООП в лучшем случае писались какие-то научные исследования, и естественно ядро БД изначально не поддерживает таких возможностей, это "не родное" для всех БД с многолетней историей...

Все-таки, мое ИМХО, нужно разделять подходы к разработке внутри БД и на Java, C# и т.д. Внутри БД нужно использовать те механизмы, которые наиболее оптимальны и проверены временем, а не изобретать велосипеды для реализации стандартных задач.

Оно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака.

Просто вы не умеете его готовить (с) не моё
во-первых что имеется ввиду конкретно показано не было. Понятно что это от недостатка опыта. Но это не причина для того, чтобы еще и язвить. Нужно лучше учиться отстаивать свою позицию.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174582
казинак
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old NickОно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака.
да ладно...
все как раз ровно наоборот происходит: "Мы слышали что ооп - это круто, так што давайте везде и всюду только его использовать"
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174649
Фотография defragmentator
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакOld NickОно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака.
да ладно...
все как раз ровно наоборот происходит: "Мы слышали что ооп - это круто, так што давайте везде и всюду только его использовать"

Да, как в анекдоте: "мыши кололись, плакали, но ели кактус"
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174651
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
казинакOld NickОно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака.
да ладно...
все как раз ровно наоборот происходит: "Мы слышали что ооп - это круто, так што давайте везде и всюду только его использовать"

Я не говорил, что ООП надо везде использовать. Сначала новички не знают что такое ООП, потом начинаю использовать везде, и только когда появляется опыт, то используют только там где это нужно.
Я не использую ООП, когда играюсь с атрибутами объектов (полями). В моих сущностях нет полей, есть только операции. С полями лучше на уровне SQL играться.
В бизнес-логике я наследование практически не использую, вложенность операций даёт больше удобств.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38174937
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old NickОчень часто в конторах, которые занимаются разработкой ПО для собственных нужд, да и для внедрения у заказчиков работает несколько разработчиков БД. Это связано прежде всего с неправильно проектированной архитектурой приложения.

Как считаете, может быть такая ситуация, что пишется крупный проект и при этом разработчик БД один и занят всего процентов на 30? И если нет, то как сделать так, чтобы было именно так?Легко! Свалить всё без разбору в EAV и выпереть всю бизнес-логику в клиентские приложения. Разработчик БД вообще не понядобится...
...в отличие от многочисленных тестеров клиентских аппликух и толстого-толстого саппорта.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175200
Фотография Amberit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old Nick,

авторОно и понятно. Это ведь из-за недостатка опыта.

Если возможно, объясните пожалуйста неопытному, что имеется в виду под "ООП в базе".

Я возьму на себя смелость пройтись по Вашим постам:

авторИ есть другой подход - использовать наработки, дописывая только то что нужно для новой прикладной логики. Согласен, но где здесь ООП?

авторЯ использую объектно-ориентированный подход с проектированию БД. Естественно есть базовые классы, базовая логика. В полной мере используется наследование, которое сводится к простому добавлению новых классов. Классы справочников, причем типовые справочники уже есть. Классы новых документов, типовые тоже уже есть. Классы бизнес-процессов.

Какие классы имеются в виду? Большинство данных в БД хранится в таблицах. Классы можно использовать для обработки этих данных. И как при добавлении нового справочника обойтись только добавлением класса? Или Вы хотите сказать, что все данные всех справочников хранятся в одной мега-таблице? Или Вы хотите сказать, что ограничения/триггера Вы не используете, а всю проверку при вставке/обновлении/удалении делаете через классы, а то и вообще вне БД (интересно, как!)?

Я искренне не понимаю, и если бы Вы объяснили Ваш подход именно с позиции разработчика БД, возможно, на одного программиста с недостаточным опытом стало бы меньше...

авторЯ не говорил, что ООП надо везде использовать. Сначала новички не знают что такое ООП, потом начинаю использовать везде, и только когда появляется опыт, то используют только там где это нужно.

Так вот меня и терзают смутные сомнения, нужно ли ООП на уровне БД? Покажите пример реализации чего-нибудь с помощью ООП в БД, если Вас не затруднит...
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175403
kmaw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну хорож уже цепляться к этим "аксиомам". суть цитаты относительно общего контекста вполне понятна и имеет практическую ценность - что с ООП, что без оного - в конце концов имеем некоторый прикладной "метаязык" - API. так вот тут говорится о том, что API, которое "идет от алгоритмов" - более прагматическое, чтоли. Так как "сразу сочинять классы" - и вот тут суть цитаты - как "изначально сочинять аксиомы"
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175489
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AmberitOld Nick,

авторОно и понятно. Это ведь из-за недостатка опыта.

Если возможно, объясните пожалуйста неопытному, что имеется в виду под "ООП в базе".

Я возьму на себя смелость пройтись по Вашим постам:

авторИ есть другой подход - использовать наработки, дописывая только то что нужно для новой прикладной логики. Согласен, но где здесь ООП?

авторЯ использую объектно-ориентированный подход с проектированию БД. Естественно есть базовые классы, базовая логика. В полной мере используется наследование, которое сводится к простому добавлению новых классов. Классы справочников, причем типовые справочники уже есть. Классы новых документов, типовые тоже уже есть. Классы бизнес-процессов.

Какие классы имеются в виду? Большинство данных в БД хранится в таблицах. Классы можно использовать для обработки этих данных. И как при добавлении нового справочника обойтись только добавлением класса? Или Вы хотите сказать, что все данные всех справочников хранятся в одной мега-таблице? Или Вы хотите сказать, что ограничения/триггера Вы не используете, а всю проверку при вставке/обновлении/удалении делаете через классы, а то и вообще вне БД (интересно, как!)?

Я искренне не понимаю, и если бы Вы объяснили Ваш подход именно с позиции разработчика БД, возможно, на одного программиста с недостаточным опытом стало бы меньше...

авторЯ не говорил, что ООП надо везде использовать. Сначала новички не знают что такое ООП, потом начинаю использовать везде, и только когда появляется опыт, то используют только там где это нужно.

Так вот меня и терзают смутные сомнения, нужно ли ООП на уровне БД? Покажите пример реализации чего-нибудь с помощью ООП в БД, если Вас не затруднит...


А, например, вот здесь

класс Document

Код: sql
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.
include=System\Object.sql
include=System\Module.sql
include=System\Application.sql
include=Subjects\Person.sql
go

exec Folder 'Root.Docs', 'Документы'
go

exec Class 'Document', 'Object', 'Абстрактный документ', 0
  exec Field 'Number', 'String', 'Номер', 'null'
  exec Field 'Date', 'Date', 'Дата', 'null'
  exec Field 'Manager', 'Person', 'Менеджер', 'null^Folder=Root.Refs.Subjects.Persons'
  exec Field 'BaseDoc', 'Document', 'Документ-основание', 'null^Folder=Root.Docs'
  exec Action 'Print', 'Распечатать'
  --exec Event 'Register', 'Регистрация документа'
exec Compile
go

create procedure Document_GetDefaultRegistrator
as
  set nocount on
  select distinct 
         a.DocRegisterOID,
         a.DocRegisterName,
         a.DocRegisterClass
    from VModule_Users u
           join
         VApplication a
           on a.OID = u.OID
    where u.UserOID = dbo.CurrentUser()
go

create procedure Document_GetChildDocs
  @OID OID
as
  set nocount on
  select t.*
    from VTree t
           join
         VClassTree ct
           on ct.BaseClass = t.Class
           and ct.Class = 'Document'
    where t.ParentOID = @OID
      and t.HierarchyOID = (select OID from VHierarchy where Ext = 'Documents')
go

create procedure Document_Register
  @OID OID
as
  set nocount on
  declare @EventOID OID
  
  select @EventOID = OID from VEvent where Ext = 'Register'
  exec Event_Throw @EventOID, @OID
go



Операционный документ
Код: sql
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.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
include=Docs\Document.sql
include=Refs\Currency.sql
include=Things\Thing.sql
go

exec Class 'OperDoc', 'Document', 'Операционный документ', 0
  exec Field 'Agent', 'Subject', 'Юридическое лицо', 'Folder=Root.Refs.Subjects'
  exec Field 'Counter', 'Subject', 'Контрагент', 'null^Folder=Root.Refs.Subjects'
  exec Field 'Currency', 'Currency', 'Валюта', 'null^Folder=Root.Refs.Currencies'
  exec Field 'Summa', 'Money', 'Сумма', 'null'
  exec Field 'SummStr', 'String', 'Сумма Прописью', 'null'
  exec Field 'Comments', 'MaxString', 'Комментарий', 'null'
  exec SubTable 'Things' , 'Товары и услуги'
    exec Field 'RowID', 'Integer', '', 'Identity(1, 1) Key'
    exec Field 'Thing', 'Thing', 'Объект учета', 'Key^Folder=Root.Refs.Things'
    exec Field 'Agent', 'Subject', 'Субагент', 'null^Folder=Root.Refs.Subjects'
    exec Field 'Counter', 'Subject', 'Субконтрагент', 'null^Folder=Root.Refs.Subjects'
  exec SubTable 'Measures', 'Измерения'
    exec Field 'RowID', 'Integer', '', 'Key'
    exec Field 'Measure', 'Measure', 'Измерение', 'Key^Folder=Root.Refs.Measures'
    exec Field 'Unit', 'Unit', 'Ед. изм.', 'Folder=Root.Refs.Units'
    exec Field 'Quantity', 'Money', 'Количество'
  exec SubTable 'Operations', 'Операции'
    exec Field 'Operation', 'Operation', '', 'Key^Folder=Root.System.Operations'
exec Compile
go

create procedure OperDoc_Transact
  @OID OID
as
  set nocount on
  declare @TransactionOID OID,
          @Err            int
          
  declare Walker cursor local fast_forward for
    select TransactionOID
      from TOperDoc_Transactions
      where OID = @OID
      
  open Walker
    fetch next from Walker into @TransactionOID
    while @@fetch_status = 0
    begin
      exec @Err = Transaction_Execute @TransactionOID, @OID
      if @Err <> 0 return 1
      fetch next from Walker into @TransactionOID
    end
  close Walker
  deallocate Walker
go

create procedure OperDoc_Transact
  @OID         OID,
  @RegisterOID OID
as
  set nocount on
  declare @Date            datetime,
          @AgentOID        OID,
          @CounterOID      OID,
          @TranID          int,
          @MeasureOID      OID,
          @UnitOID         OID,
          @ThingOID        OID,
          @Err             int,
          @Quantity        int,
          @DebitOID        OID,
          @CreditOID       OID,
          @RowID           int
  
  select @Date        = dbo.Date(Date),
         @AgentOID    = AgentOID,
         @CounterOID  = CounterOID
    from VOperDoc 
    where OID = @OID
    
  declare Things cursor local fast_forward for
    select t.RowID, t.ThingOID, isnull(t.AgentOID, @AgentOID), isnull(t.CounterOID, @CounterOID)
      from TOperDoc_Things t
      where t.OID = @OID
      
  open Things
    fetch next from Things into @RowID, @ThingOID, @AgentOID, @CounterOID
    while @@fetch_status = 0
    begin
      exec @Err = Register_AddTran @RegisterOID, @OID, @Date, @AgentOID, @CounterOID, @ThingOID, @TranID output
      if @Err <> 0 return 1
      
      declare Measures cursor local fast_forward for
        select m.MeasureOID, m.UnitOID, m.Quantity
          from TOperDoc_Measures m
          where m.OID = @OID 
            and m.RowID = @RowID
            
      open Measures
        fetch next from Measures into @MeasureOID, @UnitOID, @Quantity
        while @@fetch_status = 0
        begin
          exec @Err = Register_AddMeasure @RegisterOID, @TranID, @MeasureOID, @UnitOID, @Quantity
          if @Err <> 0 return 1
          fetch next from Measures into @MeasureOID, @UnitOID, @Quantity
        end
      close Measures
      deallocate Measures
      
      declare Accounts cursor local fast_forward for
        select a.DebitOID, a.CreditOID
          from TOperDoc_Accounts a
          where a.OID = @OID
            and a.RowID = @RowID
            
      open Accounts
        fetch next from Accounts into @DebitOID, @CreditOID
        while @@fetch_status = 0
        begin
          exec @Err = Register_AddCorresponse @RegisterOID, @TranID, @DebitOID, @CreditOID
          if @Err <> 0 return 1
          fetch next from Accounts into @DebitOID, @CreditOID
        end
      close Accounts
      deallocate Accounts
            
      fetch next from Things into @RowID, @ThingOID, @AgentOID, @CounterOID
    end
  close Things
  deallocate Things
go
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175508
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Или вот простой справочник без дополнительных полей

Код: sql
1.
2.
3.
exec Class 'Bank', 'Company', 'Банк' 
exec Compile
GO




Справочник посложнее

Код: sql
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.
include=Subjects\Subject.sql
go

exec Folder 'Root.Refs.Subjects.Departments', 'Подразделения'
go

exec Class 'Department', 'Subject', 'Отдел'
  exec SubTable 'Positions', 'Должности'
    exec Field 'Position', 'Position', 'Должность', 'Key'
exec Compile
go

create procedure Department_Staffs_Select
  @OID  OID,
  @Date datetime = null
as
  set nocount on
  
  set @Date = isnull(@Date, dbo.ToDay())
  
  select distinct
         StaffOID = s.OID,
         StaffName = s.Name,
         StaffClass = s.Class,
         s.PositionOID,
         s.PositionName,
         s.PositionClass,
         sh.PersonOID,
         sh.PersonName,
         sh.PersonClass,
         s.ParentOID,
         s.ParentName,
         s.ParentClass,
         ss.StateOID,
         ss.StateName,
         ss.StateClass
    from VTreePath tp
           join
         VDepartment d
           on d.OID = tp.ChildOID
           join
         VStaff s
           on s.DepartmentOID = d.OID
           join
         VStaff_States ss
           on ss.OID = s.OID
           and ss.Date = (select max(Date)
                            from VStaff_States
                            where OID = ss.OID
                              and Date <= @Date)
           join
         VStaff_History sh
           on sh.OID = s.OID
           and sh.Date = (select max(Date)
                            from VStaff_History
                            where OID = sh.OID
                              and Date <= @Date)
    where tp.ParentOID = @OID
      and tp.HierarchyOID = (select OID from VHierarchy where Ext = 'Legal')
go
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175630
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old Nick,

две OpenDoc_Transact с одинаковым именем как в БД появятся?
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175634
Фотография iv_an_ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old Nick,

может простынки кода прятать под маленький аккуратный плюсик? Или дать ссылку на репозиторий :)
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175705
ДжекНепотрошитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old Nick
класс Document

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
include=System\Object.sql
include=System\Module.sql
include=System\Application.sql
include=Subjects\Person.sql
go

exec Folder 'Root.Docs', 'Документы'
go

exec Class 'Document', 'Object', 'Абстрактный документ', 0
  exec Field 'Number', 'String', 'Номер', 'null'
  exec Field 'Date', 'Date', 'Дата', 'null'
  exec Field 'Manager', 'Person', 'Менеджер', 'null^Folder=Root.Refs.Subjects.Persons'
  exec Field 'BaseDoc', 'Document', 'Документ-основание', 'null^Folder=Root.Docs'
  exec Action 'Print', 'Распечатать'
  --exec Event 'Register', 'Регистрация документа'
exec Compile
go


Понятно. Чем это лучше create table, кроме возможности указания заголовков для полей? И как этот механизм позволяет управлять оптимизацией запросов, например?
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175737
Фотография Amberit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Old Nick,

Ок, спасибо за пример, давайте рассмотрим Ваш подход. К сожалению, я ни разу не спец в Transact-SQL, поэтому некоторые вещи мог неверно истолковать исходя из моих знаний ORACLE. Давайте рассмотрим Ваш подход к работе со справочниками.

Безотносительно к БД, необходимо совершать следующие действия над ними: просмотр, добавление, изменение, удаление элементов справочника.

1. Просмотр. У Вас реализован - ОК.
2. Добавление новой записи - НЕТ.
3. Редактирование существующей записи - НЕТ.
4. Удаление существующей записи - НЕТ.
5. Проверки при добавлении, редактировании, удалении - НЕТ.
6. Управление правами доступа к элементам справочника (в т.ч. на уровне строк) - НЕТ (или не применяется).
7. Логгирование действий со справочником (история изменений) - НЕТ (или не применяется).
8. Для особо критичных справочников - использование верификации (один вводит, другой подтверждает) - НЕТ (или не применяется).

Итого - приведенный пример неполон, т.к. не показана реализация основных действий со справочником. Или эти моменты у Вас реализованы не на стороне БД, а на стороне клиентского приложения (WEB-сервера)?

Из-за того, что вся информация о данных справочников хранится в строго ограниченном перечне таблиц, вытекает следующее:
1. Невозможность использования внешних ключей в принципе. Т.е., например, при удалении записи из справочника нужно дополнительно прописывать проверку, что для этой записи нет зависимостей и ее можно удалять. Иначе получим неконсистентные данные в БД.
2. Непонятно, как организовано хранение данных разных типов. Все приводится к строчному типу? Или какому-нибудь абстрактному типу а-ля ANYDATA в ORACLE?
3. По структуре БД нельзя обнаружить зависимости, вся логика находится в обрабатывающих процедурах.
4. Невозможность (затруднительность) использования триггеров/ограничений БД, т.к. их логика, судя по всему, будет сильно запутанна.
5. Скорее всего, ваша БД жестко привязана только к одному приложению. Использование БД с другим приложением потребует клонирования функционала.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175745
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmOld Nick,

две OpenDoc_Transact с одинаковым именем как в БД появятся?

Почему две то? Одна. При повторной загрузке в БД делается alter. Только это всё не ручками, а через программу SQLEditor.exe
Эту программу я написал сам для своих нужд и теперь не парясь пишу create table, create view, create procedure и т.д. Программа сама отслеживает есть объект в базе или нет и если есть, то меняет слово CREATE на ALTER
Для таблиц механизм сложнее. Таблица пересоздается не теряя данные.

Очень удобно знаете ли заливать целиком проект в базу не думая какая при этом текущая структура. После заливки структура становится по последней версии. И данные не трогаются. При этом всём целостное обновление структуры происходит в транзакции и если хоть где-то происходит ошибка или нестыковка, то происходит откат версии и пользователи ничего не замечают
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175753
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ДжекНепотрошительOld Nickкласс Document

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
include=System\Object.sql
include=System\Module.sql
include=System\Application.sql
include=Subjects\Person.sql
go

exec Folder 'Root.Docs', 'Документы'
go

exec Class 'Document', 'Object', 'Абстрактный документ', 0
  exec Field 'Number', 'String', 'Номер', 'null'
  exec Field 'Date', 'Date', 'Дата', 'null'
  exec Field 'Manager', 'Person', 'Менеджер', 'null^Folder=Root.Refs.Subjects.Persons'
  exec Field 'BaseDoc', 'Document', 'Документ-основание', 'null^Folder=Root.Docs'
  exec Action 'Print', 'Распечатать'
  --exec Event 'Register', 'Регистрация документа'
exec Compile
go


Понятно. Чем это лучше create table, кроме возможности указания заголовков для полей? И как этот механизм позволяет управлять оптимизацией запросов, например?

Заметьте что тут есть процедура Compile. Она по вновь созданным или измененным метаданным начинает создавать или пересоздавать

1. Таблицы
2. Вьюхи с instead of triggers
3. Хранимые процедуры выборки, вставки, изменения, удаления
4. Разные вспомогательные объекты

Оптимизировать такие процедуры нет необходимости. Остальные методы классов и объектов это всего лишь хранимки на T-SQL
Они пишутся обычным текстом и там если нужно то оптимизируется.

Снаружи доступ есть только к вьюхам. Таблицы не видны - это и есть инкапсуляция.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175759
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ДжекНепотрошительЧем это лучше create table, кроме возможности указания заголовков для полей?
там суть не в заголовках похоже. В приведенном примере обратите внимание на а-ля типы данных Person, Document:

Код: sql
1.
2.
  exec Field 'Manager', 'Person', 'Менеджер', 'null^Folder=Root.Refs.Subjects.Persons'
  exec Field 'BaseDoc', 'Document', 'Документ-основание', 'null^Folder=Root.Docs'



просто по какой-то причине OldNick не комментирует то, что показывает... только потому что нечто подобным занимался в начале 90-х в unix, была гипертекстовая СУБД, направление мыслей ТС понятно.
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175771
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В результате у меня полноценная ООП - система с наследованием, инкапсуляцией, полиморфизмом, где сущность - это не класс в каком либо языке, а совокупность таблиц, вьюх, хранимок, метаданных, классов, форм и т.д. Сущность проходит через всю систему насквозь. От БД через АппСервер до интерфейса.

И примечательно то, что логика обрабатывается через ООП, а данные через SQL
...
Рейтинг: 0 / 0
Эффективность разработки ПО
    #38175780
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmДжекНепотрошительЧем это лучше create table, кроме возможности указания заголовков для полей?
там суть не в заголовках похоже. В приведенном примере обратите внимание на а-ля типы данных Person, Document:

Код: sql
1.
2.
  exec Field 'Manager', 'Person', 'Менеджер', 'null^Folder=Root.Refs.Subjects.Persons'
  exec Field 'BaseDoc', 'Document', 'Документ-основание', 'null^Folder=Root.Docs'



просто по какой-то причине OldNick не комментирует то, что показывает... только потому что нечто подобным занимался в начале 90-х в unix, была гипертекстовая СУБД, направление мыслей ТС понятно.

Manager - Имя поля
Person - тип поля - объектный
Менеджер - Caption - отображается в заголовках грида или в Label полей
А дальше допатрибуты через ^
...
Рейтинг: 0 / 0
25 сообщений из 127, страница 3 из 6
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Эффективность разработки ПО
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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