|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
U-gene2 sphinx_mv Ну Вы хоть в Википедии посмотрите, что такое аксиома, или вспомните, с чего геометрию начинали изучать (с аксиоматических понятий "точка" и "прямая"). А тоВы лепите, не думая, а впечатление, чтоВы не думаете. В статьях по ссылкам был же ответ. Готовая математическа конструкция (доказательство теоремы/правильности алгоритма/описания способа вычислений) базируется/cтроится на утверждениях, называемых аксиомами. Но придумывание/конструирование этой конструкции не с аксиом начинают. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 11:17 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Old Nick, авторИ мне кажется мы разные вещи понимаем под словами ООП в базе Наверное, в этом и загвоздка. По-моему, Вы недостаточно четко разъяснили, что имеете в виду под "ООП в базе", и у большинства камрадов это вызвало "легкое" недоумение... В ORACLE (не знаю как в других БД, в них я не копенгаген) ООП на уровне SQL, PL/SQL - это, мягко говоря, нужно как козе баян. Конечно, некоторые возможности есть, и их даже можно/нужно использовать в определенных случаях, но почти всегда их можно безболезненно заменить на процедурный подход (в PL/SQL) или переделать в реляционную модель (SQL). Такой подход почти всегда (за редкими исключениями) более понятен, сопровождаем, имеет лучшую производительность. Ведь реализация БД появилась в те времена, когда об ООП в лучшем случае писались какие-то научные исследования, и естественно ядро БД изначально не поддерживает таких возможностей, это "не родное" для всех БД с многолетней историей... Все-таки, мое ИМХО, нужно разделять подходы к разработке внутри БД и на Java, C# и т.д. Внутри БД нужно использовать те механизмы, которые наиболее оптимальны и проверены временем, а не изобретать велосипеды для реализации стандартных задач. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 11:51 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
AmberitOld Nick, авторИ мне кажется мы разные вещи понимаем под словами ООП в базе Наверное, в этом и загвоздка. По-моему, Вы недостаточно четко разъяснили, что имеете в виду под "ООП в базе", и у большинства камрадов это вызвало "легкое" недоумение... В ORACLE (не знаю как в других БД, в них я не копенгаген) ООП на уровне SQL, PL/SQL - это, мягко говоря, нужно как козе баян. Конечно, некоторые возможности есть, и их даже можно/нужно использовать в определенных случаях, но почти всегда их можно безболезненно заменить на процедурный подход (в PL/SQL) или переделать в реляционную модель (SQL). Такой подход почти всегда (за редкими исключениями) более понятен, сопровождаем, имеет лучшую производительность. Ведь реализация БД появилась в те времена, когда об ООП в лучшем случае писались какие-то научные исследования, и естественно ядро БД изначально не поддерживает таких возможностей, это "не родное" для всех БД с многолетней историей... Все-таки, мое ИМХО, нужно разделять подходы к разработке внутри БД и на Java, C# и т.д. Внутри БД нужно использовать те механизмы, которые наиболее оптимальны и проверены временем, а не изобретать велосипеды для реализации стандартных задач. Оно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака. Просто вы не умеете его готовить (с) не моё ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 12:47 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
2 sphinx_mv, kmaw ,Inkelyad Повторю цитату "Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома." Ну если бы был глагол "подбирается" или "придумывается", то я бы не возражал. А говорить, что аксиомы 1)откуда-то 2)выводятся - бред. Имею право это отметить. И все толкования и объяснения здесь - это как сначала сказать, что "Волга вытекает из Каспийского моля" а потом начать оправдываться, что де она впадает , конечно. 2 sphinx_mv, espacially Я про ООП ни слова не сказал. По мне, так удобнее чем предыдущие структуры и функции. А аргумент про количество классов в поставке меня вообще удивляет. Например, я не перечитал всех книг, и вряд ли перечитаю. И никто не знает, сколько их есть. Но это не значит , что они вообще не нужны. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 12:49 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
sphinx_mviscrafmпропущено... плакать или смеяться? Автор может быть хоть котом в сапогах, но это не повод ляпать о том, что в бухгалтерии нет наследования.Нет в бухгалтерии наследования - и никогда не было! а выше приведенный пример не читали? Ладно, послушаем опытного бухгалтера, нет так нет. Ты автор этой статьи что-ли? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 13:10 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Вообще ООП+женерики+лямбды и прочие деревья выражений - большая сила, нужно только понимать что к чему и уметь использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 13:12 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
казинакНо появление в команде еще и болтунов-дармоедов в виде ... архитектора не принесет улучшений:) Это я по опыту говорю. поздравляю с "шикарнейшим" опытом. Только почему здесь так принято гордится этим. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 13:15 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Old NickAmberitOld Nick, пропущено... Наверное, в этом и загвоздка. По-моему, Вы недостаточно четко разъяснили, что имеете в виду под "ООП в базе", и у большинства камрадов это вызвало "легкое" недоумение... В ORACLE (не знаю как в других БД, в них я не копенгаген) ООП на уровне SQL, PL/SQL - это, мягко говоря, нужно как козе баян. Конечно, некоторые возможности есть, и их даже можно/нужно использовать в определенных случаях, но почти всегда их можно безболезненно заменить на процедурный подход (в PL/SQL) или переделать в реляционную модель (SQL). Такой подход почти всегда (за редкими исключениями) более понятен, сопровождаем, имеет лучшую производительность. Ведь реализация БД появилась в те времена, когда об ООП в лучшем случае писались какие-то научные исследования, и естественно ядро БД изначально не поддерживает таких возможностей, это "не родное" для всех БД с многолетней историей... Все-таки, мое ИМХО, нужно разделять подходы к разработке внутри БД и на Java, C# и т.д. Внутри БД нужно использовать те механизмы, которые наиболее оптимальны и проверены временем, а не изобретать велосипеды для реализации стандартных задач. Оно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака. Просто вы не умеете его готовить (с) не моё во-первых что имеется ввиду конкретно показано не было. Понятно что это от недостатка опыта. Но это не причина для того, чтобы еще и язвить. Нужно лучше учиться отстаивать свою позицию. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 13:22 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Old NickОно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака. да ладно... все как раз ровно наоборот происходит: "Мы слышали что ооп - это круто, так што давайте везде и всюду только его использовать" ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 13:51 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
казинакOld NickОно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака. да ладно... все как раз ровно наоборот происходит: "Мы слышали что ооп - это круто, так што давайте везде и всюду только его использовать" Да, как в анекдоте: "мыши кололись, плакали, но ели кактус" ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 14:34 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
казинакOld NickОно и понятно. Это ведь из-за недостатка опыта. Зато как слюной брызжут :-) Мы ООП пробовали и оно нам не понравилось :-) ржака. да ладно... все как раз ровно наоборот происходит: "Мы слышали что ооп - это круто, так што давайте везде и всюду только его использовать" Я не говорил, что ООП надо везде использовать. Сначала новички не знают что такое ООП, потом начинаю использовать везде, и только когда появляется опыт, то используют только там где это нужно. Я не использую ООП, когда играюсь с атрибутами объектов (полями). В моих сущностях нет полей, есть только операции. С полями лучше на уровне SQL играться. В бизнес-логике я наследование практически не использую, вложенность операций даёт больше удобств. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 14:35 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Old NickОчень часто в конторах, которые занимаются разработкой ПО для собственных нужд, да и для внедрения у заказчиков работает несколько разработчиков БД. Это связано прежде всего с неправильно проектированной архитектурой приложения. Как считаете, может быть такая ситуация, что пишется крупный проект и при этом разработчик БД один и занят всего процентов на 30? И если нет, то как сделать так, чтобы было именно так?Легко! Свалить всё без разбору в EAV и выпереть всю бизнес-логику в клиентские приложения. Разработчик БД вообще не понядобится... ...в отличие от многочисленных тестеров клиентских аппликух и толстого-толстого саппорта. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 17:02 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Old Nick, авторОно и понятно. Это ведь из-за недостатка опыта. Если возможно, объясните пожалуйста неопытному, что имеется в виду под "ООП в базе". Я возьму на себя смелость пройтись по Вашим постам: авторИ есть другой подход - использовать наработки, дописывая только то что нужно для новой прикладной логики. Согласен, но где здесь ООП? авторЯ использую объектно-ориентированный подход с проектированию БД. Естественно есть базовые классы, базовая логика. В полной мере используется наследование, которое сводится к простому добавлению новых классов. Классы справочников, причем типовые справочники уже есть. Классы новых документов, типовые тоже уже есть. Классы бизнес-процессов. Какие классы имеются в виду? Большинство данных в БД хранится в таблицах. Классы можно использовать для обработки этих данных. И как при добавлении нового справочника обойтись только добавлением класса? Или Вы хотите сказать, что все данные всех справочников хранятся в одной мега-таблице? Или Вы хотите сказать, что ограничения/триггера Вы не используете, а всю проверку при вставке/обновлении/удалении делаете через классы, а то и вообще вне БД (интересно, как!)? Я искренне не понимаю, и если бы Вы объяснили Ваш подход именно с позиции разработчика БД, возможно, на одного программиста с недостаточным опытом стало бы меньше... авторЯ не говорил, что ООП надо везде использовать. Сначала новички не знают что такое ООП, потом начинаю использовать везде, и только когда появляется опыт, то используют только там где это нужно. Так вот меня и терзают смутные сомнения, нужно ли ООП на уровне БД? Покажите пример реализации чего-нибудь с помощью ООП в БД, если Вас не затруднит... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.03.2013, 20:39 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
ну хорож уже цепляться к этим "аксиомам". суть цитаты относительно общего контекста вполне понятна и имеет практическую ценность - что с ООП, что без оного - в конце концов имеем некоторый прикладной "метаязык" - API. так вот тут говорится о том, что API, которое "идет от алгоритмов" - более прагматическое, чтоли. Так как "сразу сочинять классы" - и вот тут суть цитаты - как "изначально сочинять аксиомы" ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 07:26 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
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.
Операционный документ Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 09:18 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Или вот простой справочник без дополнительных полей Код: sql 1. 2. 3.
Справочник посложнее Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 09:28 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Old Nick, две OpenDoc_Transact с одинаковым именем как в БД появятся? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 10:47 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Old Nick, может простынки кода прятать под маленький аккуратный плюсик? Или дать ссылку на репозиторий :) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 10:49 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Old Nick класс Document Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Понятно. Чем это лучше create table, кроме возможности указания заголовков для полей? И как этот механизм позволяет управлять оптимизацией запросов, например? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 11:27 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
Old Nick, Ок, спасибо за пример, давайте рассмотрим Ваш подход. К сожалению, я ни разу не спец в Transact-SQL, поэтому некоторые вещи мог неверно истолковать исходя из моих знаний ORACLE. Давайте рассмотрим Ваш подход к работе со справочниками. Безотносительно к БД, необходимо совершать следующие действия над ними: просмотр, добавление, изменение, удаление элементов справочника. 1. Просмотр. У Вас реализован - ОК. 2. Добавление новой записи - НЕТ. 3. Редактирование существующей записи - НЕТ. 4. Удаление существующей записи - НЕТ. 5. Проверки при добавлении, редактировании, удалении - НЕТ. 6. Управление правами доступа к элементам справочника (в т.ч. на уровне строк) - НЕТ (или не применяется). 7. Логгирование действий со справочником (история изменений) - НЕТ (или не применяется). 8. Для особо критичных справочников - использование верификации (один вводит, другой подтверждает) - НЕТ (или не применяется). Итого - приведенный пример неполон, т.к. не показана реализация основных действий со справочником. Или эти моменты у Вас реализованы не на стороне БД, а на стороне клиентского приложения (WEB-сервера)? Из-за того, что вся информация о данных справочников хранится в строго ограниченном перечне таблиц, вытекает следующее: 1. Невозможность использования внешних ключей в принципе. Т.е., например, при удалении записи из справочника нужно дополнительно прописывать проверку, что для этой записи нет зависимостей и ее можно удалять. Иначе получим неконсистентные данные в БД. 2. Непонятно, как организовано хранение данных разных типов. Все приводится к строчному типу? Или какому-нибудь абстрактному типу а-ля ANYDATA в ORACLE? 3. По структуре БД нельзя обнаружить зависимости, вся логика находится в обрабатывающих процедурах. 4. Невозможность (затруднительность) использования триггеров/ограничений БД, т.к. их логика, судя по всему, будет сильно запутанна. 5. Скорее всего, ваша БД жестко привязана только к одному приложению. Использование БД с другим приложением потребует клонирования функционала. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 11:48 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
iscrafmOld Nick, две OpenDoc_Transact с одинаковым именем как в БД появятся? Почему две то? Одна. При повторной загрузке в БД делается alter. Только это всё не ручками, а через программу SQLEditor.exe Эту программу я написал сам для своих нужд и теперь не парясь пишу create table, create view, create procedure и т.д. Программа сама отслеживает есть объект в базе или нет и если есть, то меняет слово CREATE на ALTER Для таблиц механизм сложнее. Таблица пересоздается не теряя данные. Очень удобно знаете ли заливать целиком проект в базу не думая какая при этом текущая структура. После заливки структура становится по последней версии. И данные не трогаются. При этом всём целостное обновление структуры происходит в транзакции и если хоть где-то происходит ошибка или нестыковка, то происходит откат версии и пользователи ничего не замечают ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 11:56 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
ДжекНепотрошительOld Nickкласс Document Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Понятно. Чем это лучше create table, кроме возможности указания заголовков для полей? И как этот механизм позволяет управлять оптимизацией запросов, например? Заметьте что тут есть процедура Compile. Она по вновь созданным или измененным метаданным начинает создавать или пересоздавать 1. Таблицы 2. Вьюхи с instead of triggers 3. Хранимые процедуры выборки, вставки, изменения, удаления 4. Разные вспомогательные объекты Оптимизировать такие процедуры нет необходимости. Остальные методы классов и объектов это всего лишь хранимки на T-SQL Они пишутся обычным текстом и там если нужно то оптимизируется. Снаружи доступ есть только к вьюхам. Таблицы не видны - это и есть инкапсуляция. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 12:00 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
ДжекНепотрошительЧем это лучше create table, кроме возможности указания заголовков для полей? там суть не в заголовках похоже. В приведенном примере обратите внимание на а-ля типы данных Person, Document: Код: sql 1. 2.
просто по какой-то причине OldNick не комментирует то, что показывает... только потому что нечто подобным занимался в начале 90-х в unix, была гипертекстовая СУБД, направление мыслей ТС понятно. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 12:02 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
В результате у меня полноценная ООП - система с наследованием, инкапсуляцией, полиморфизмом, где сущность - это не класс в каком либо языке, а совокупность таблиц, вьюх, хранимок, метаданных, классов, форм и т.д. Сущность проходит через всю систему насквозь. От БД через АппСервер до интерфейса. И примечательно то, что логика обрабатывается через ООП, а данные через SQL ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 12:09 |
|
Эффективность разработки ПО
|
|||
---|---|---|---|
#18+
iscrafmДжекНепотрошительЧем это лучше create table, кроме возможности указания заголовков для полей? там суть не в заголовках похоже. В приведенном примере обратите внимание на а-ля типы данных Person, Document: Код: sql 1. 2.
просто по какой-то причине OldNick не комментирует то, что показывает... только потому что нечто подобным занимался в начале 90-х в unix, была гипертекстовая СУБД, направление мыслей ТС понятно. Manager - Имя поля Person - тип поля - объектный Менеджер - Caption - отображается в заголовках грида или в Label полей А дальше допатрибуты через ^ ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2013, 12:13 |
|
|
start [/forum/topic.php?fid=33&msg=38174285&tid=1547725]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
29ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 149ms |
0 / 0 |