AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 30.01.2006, 13:57   #81  
ibc is offline
ibc
Участник
Аватар для ibc
 
472 / 30 (2) +++
Регистрация: 12.05.2003
Адрес: Москва
Цитата:
Не сильно облегчает, т.к. не является полноценным ООП.
Наличие полноценного ООП, т.е. наследования таблиц и др. объектов очевидно в ближайшем будущем ожидать не следует...
Цитата:
в сочетании со сложной иерархией
А, что по вашему мнению АОТ можно было бы упростить?
Старый 08.02.2006, 18:28   #82  
Pavel is offline
Pavel
SAP
SAP
 
2,760 / 239 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Цитата:
Сообщение от macklakov
Затем, что главное назначение РБД, быстрый доступ к данным на МАГНИТНОМ носителе. Но с 64-х разрядной архитектурой, можно будет всю базу держать в оперативной памяти, а сохранение на диск будет аналогом бэкапа.
Если следовать информации из новостной ленты, то СУБД в памяти уже реальность и имеет коммерческое использование.

"Краткая характеристика СУБД TimesTen состоит в том, что за счет хранения баз данных целиком в основной памяти и соответствующей оптимизации структур хранения и индексирования система обеспечивает очень высокую производительности (в десять раз превосходящую производительность традиционных СУБД) при выполнении операций выборки из базы данных. В типичном сценарии использования TimesTen база данных целиком загружается в основную память с дисков при старте системы, и все операции над базой данных выполняются без обращения к дискам."
подробности здесь - http://citcity.ru/11418/

Цитата:
Сообщение от macklakov
Соответственно, реляционное представление данных должно потерять свою актуальность, данные и способы обработки станут более приближенными к предметной деятельности. А ООП, хороший способ их систематизировать.
Ничего этого нет, абсолютно классическое построение СУБД и в 32-х и в 64-х битном исполнении.
За это сообщение автора поблагодарили: macklakov (5).
Старый 08.02.2006, 18:55   #83  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от Pavel
Ничего этого нет, абсолютно классическое построение СУБД и в 32-х и в 64-х битном исполнении.
В данном продукте нет, но в других продуктах будут и нереляционные структуры использоваться. Да и реляционные сущности уже начинают превращаться в классы с объектами-записями, т.к. на них навешано слишком много кода.
__________________
Isn't it nice when things just work?
Старый 09.02.2006, 19:50   #84  
Pavel is offline
Pavel
SAP
SAP
 
2,760 / 239 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Цитата:
Сообщение от macklakov
В данном продукте нет, но в других продуктах будут и нереляционные структуры использоваться. Да и реляционные сущности уже начинают превращаться в классы с объектами-записями, т.к. на них навешано слишком много кода.
Всего лишь конкретный пример.
Возможно, он и не определяет путей стратегического развития БД, но в пределах нашей теоретической дискуссии не помешает немного конкретики и фактов из жизни.
Старый 10.02.2006, 14:07   #85  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
Мне когда-то запала в душу такая цитата:

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

(Д.П.Мак-Манус. Обработка баз данных на Visual Basic 6 - СПб, Вильямс, 1999 - стр.374, 3-й абзац сверху)
Старый 13.02.2006, 13:46   #86  
ibc is offline
ibc
Участник
Аватар для ibc
 
472 / 30 (2) +++
Регистрация: 12.05.2003
Адрес: Москва
Цитата:
Во многих случаях использование записи в базе данных в качестве объекта,
образно говоря, подобно попытке вставить круглый колышек в не совсем круглое отверстие."
Угу! Но если в качестве объекта будет ВСЯ таблица со всеми записями?
Ася?
Старый 13.02.2006, 13:58   #87  
mit is offline
mit
Участник
Аватар для mit
 
386 / 36 (2) +++
Регистрация: 15.01.2003
Адрес: Moscow
как раз таблица вписывается в объектную модель. автор видимо имеет ввиду именно запись, причем полученную путем выборки из нескольких таблиц, связь 1:н. поправьте, если не прав.
Старый 13.02.2006, 14:40   #88  
Pavel is offline
Pavel
SAP
SAP
 
2,760 / 239 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Цитата:
Сообщение от Gustav
Во многих случаях использование записи в базе данных в качестве объекта, образно говоря, подобно попытке вставить круглый колышек в не совсем круглое отверстие.
У каждого способа хранения информации есть свои особенности (не стал бы их называть преимуществами и недостатками), которыми в определенных условиях можно воспользоваться.

Например, в студенческие времена решал задачу идентификации в полупроводниковых кристаллах электрических схем (программа была С++). Кристалл описывался трехмерной матрицей (сечения по осям координат), а его электрическая схема сохранялась в неоднородном списке. Матрицу удобно хранить и обрабатывать в РБД, а электрическую схему - в виде связанных списком объектов.
Старый 13.02.2006, 16:05   #89  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от Pavel
У каждого способа хранения информации есть свои особенности (не стал бы их называть преимуществами и недостатками), которыми в определенных условиях можно воспользоваться.
Ключевое слово ХРАНЕНИЕ. Именно поэтому мы не можем понять точку зрения дург друга. В РБД данные удобно ХРАНИТЬ, а потом быстро ИСКАТЬ, а в ООП удобно ОБРАБАТЫВАТЬ, т.к. данные и способ их обработки связаны между собой и структуры данных не ограничены реляционной моделью, хотя и могут ее реализовывать.
Что касается темы обсуждения, то мое мнение такое: использование ООП слабо согласуется с ERP, т.к. основная цель языка все же ограничить прикладного разработчика
Реальную технологическую выгоду от использования ООП можено было бы получить при использовании бизнес-копонент, написанных, на полноцнных языках, из которых можно было бы составлять свои системы. Но IMHO продажа таких компонент не даст тех прибылей, кторые дает комплексное внедрение

OFFTOP
Цитата:
Сообщение от Pavel
в студенческие времена решал задачу идентификации в полупроводниковых кристаллах электрических схем
Ай как нехорошо! Это же форменное пиратство!
__________________
Isn't it nice when things just work?
За это сообщение автора поблагодарили: Yoil (4).
Старый 13.02.2006, 16:34   #90  
Pavel is offline
Pavel
SAP
SAP
 
2,760 / 239 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Цитата:
Сообщение от macklakov
Ай как нехорошо! Это же форменное пиратство!
Обычная реакция с которой приходилось сталкиваться на всякого рода научных конференциях.

На самом деле программа была частью большой системы (САПР СБИС), осуществлявшей полный цикл моделирования процесса проектирования кристаллов:
- синтез кристаллов по ограничениям конкретной технологии
- экстрация электрических схем
- схемотехнический анализ эл.схемы и идентификация логических функций
Без компьютерного моделирования создавать новые кристаллы долго и дорого.
Старый 13.02.2006, 16:49   #91  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Жуткий OFFTOP
Цитата:
Сообщение от Pavel
- синтез кристаллов по ограничениям конкретной технологии
- экстрация электрических схем
- схемотехнический анализ эл.схемы и идентификация логических функций
Т.е. самих полупроводниковых кристаллов все же не было, а была их физическая модель И вы сверяли результат с тем, что ожидали изначально получить? Тогда не пиратство, забираю свои слова обратно
__________________
Isn't it nice when things just work?
Старый 14.02.2006, 17:50   #92  
Recoilme is offline
Recoilme
злыдень
Аватар для Recoilme
Злыдни
 
895 / 192 (8) ++++++
Регистрация: 18.06.2003
Цитата:
Сообщение от Gustav
Мне когда-то запала в душу такая цитата:

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

(Д.П.Мак-Манус. Обработка баз данных на Visual Basic 6 - СПб, Вильямс, 1999 - стр.374, 3-й абзац сверху)
Статья Тенцера, описывающая на небольшом примере: "как именно можно вставить круглый колышек в квадратную БД"
сцылка
ЗЫ: имхо - это уже мегапроктология
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/
Старый 15.02.2006, 18:39   #93  
Recoilme is offline
Recoilme
злыдень
Аватар для Recoilme
Злыдни
 
895 / 192 (8) ++++++
Регистрация: 18.06.2003
Вот ещё очень верное, на мой взгляд, определение ООП:
Цитата:
Соответственно считается, что "граблеперенесение" повысит качество и надежность ПО
взято тут:
http://sql.ru/forum/actualthread.aspx?tid=262026&hl=net
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/
Старый 21.08.2006, 11:20   #94  
Recoilme is offline
Recoilme
злыдень
Аватар для Recoilme
Злыдни
 
895 / 192 (8) ++++++
Регистрация: 18.06.2003
Thumbs up
Наткнулся, тут... прям неудержался от цитаты))) :

Цитата:
Кстати, я вовсе не предрекаю гибель объектно-ориентированного подхода. Хотя, по моему мнению, за исключением некоторых специализированных областей применения, объектно-ориентированность ничего не даёт хорошим программистам, она очень привлекательна для больших организаций. ООП - это приличный способ написания путаного лапшеобразного кода, позволяющий строить программы в виде серии патчей. Большие организации всегда были склонны разрабатывать программное обеспечение таким образом, и думаю, этому и через сто лет не измениться.
Пол Грэм, Языки программирования через сто лет
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/
Старый 22.08.2006, 14:16   #95  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
Цитата:
Сообщение от Recoilme
Наткнулся, тут... прям неудержался от цитаты)))
Душевно.
Да там уже прямо с самого начала увлекательно:
Цитата:
Языки программирования, подобно формам жизни, образуют эволюционное древо. На этом древе есть и тупиковые ветви, и некоторые из них уже известны. Кобол, несмотря на всю свою популярность в былые годы, похоже, не оставил интеллектуальных потомков.

Я считаю, что похожая судьба ждёт и Джаву. Люди спрашивают меня: "Как можно говорить, что Джаве не быть? Она уже стала успешным языком". И я не могу не согласиться с ними. Джава - успешный язык, если считать мерилом успеха площадь полок с учебниками Джавы в книжных магазинах или количество студентов, убеждённых, что знание Джавы поможет им найти работу. Я имел в виду другое. Мне кажется, Джава окажется таким же эволюционным тупиком, как Кобол.
П.Грэм. Языки программирования через сто лет
Старый 22.08.2006, 14:47   #96  
eugene egorov is offline
eugene egorov
Участник
Аватар для eugene egorov
 
273 / 97 (4) ++++
Регистрация: 05.06.2002
Адрес: Москва
Йоды магистра речи тайна открыта. Оказывается на фортране программист старый есть он.
__________________
любитель портвейна и снов с прокисшей капустой в усах
Старый 22.08.2006, 18:04   #97  
Recoilme is offline
Recoilme
злыдень
Аватар для Recoilme
Злыдни
 
895 / 192 (8) ++++++
Регистрация: 18.06.2003
Цитата:
Сообщение от Gustav
Душевно.
Ага, меня тоже радует он (сорри первым язагом был фортран )))..
Ещё чтоб погреть тебе сердце:
Цитата:
Я где-то читал, что язык Java не так давно стал самым популярным инструментом программирования, опередив по популярности "Кобол". Для языка, как стандарта, это, безусловно, большой успех. Но в качестве среды для творчества языку Java еще есть, к чему стремиться. Из всех знакомых мне выдающихся программистов я знаю только одного человека, который добровольно выбрал бы язык Java для работы. Да и то, в связи с тем, что этот человек работает в фирме Sun Microsystems.

И специально для тебя - небольшоя подборочка:
http://webradar.ru/
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/
Старый 23.08.2006, 15:54   #98  
Maximin is offline
Maximin
NavAx
NavAx Club
 
408 / 341 (12) ++++++
Регистрация: 09.10.2002
Адрес: Москва
Спор ни о чём. Технология ради технологии никому не нужна.
Взять тот же процессор i860. Замечательный проц, куча новых технологий.
И где он? Где те же Itanium? Весь мир до сих пор сидит на x86, ибо пока он устраивает всех. Правда, от оригинального x86 всё меньше и меньше остается.

Что касается ODB - как только РЕЗКО появятся такие задачи, которые нельзя будет решить на РДБ - так они и пойдут в рост. А так - классические РДБ будут и дальше обрастать объектно-подобной мишурой. Или пока кто-нибудь не придумает некий подход, который объединит обе концепции в единую новую.
__________________
Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты...
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
ERP-системы — мэйнстрим или тупиковая ветвь? slava09 Курилка 30 26.09.2010 18:00
Консультант по внедрению ERP-систем 250 тыс. р. miklenew Курилка 4 13.01.2009 23:30
Встреча специалистов по внедрению ERP и CRM систем в клубе "Пегас" 5 декабря 2008 года George Nordic Курилка 90 09.12.2008 00:45
Практика подготовки к внедрению ERP-систем slava09 Курилка 4 08.10.2008 11:29
Встреча ИТ-специалистов в области ERP-систем в г. Москва 12 августа 2005г. George Nordic Курилка 115 21.09.2005 10:17
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 12:37.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.