Comments 32
Мне кажется, что многие ваши проблемы намного легче можно решить используя НЕреляционные ДБ, а само приложение строить на основе OSGI.
Если вам так кажется, то может выскажите конкретные предположения о возможной реализации и расскажете о производительности подобного решения?
А что вас конкретно интересует?
Ну например тут — не реляционный подход (фактически база ключ-значение с построением дополнительных индексов) поверх реляционной БД
habrahabr.ru/blogs/mysql/87147/
Ну и традиционно: MongoDB, например
habrahabr.ru/blogs/mysql/87147/
Ну и традиционно: MongoDB, например
OSGI не решит проблему динамического изменения структуры данных без изменения кода. Это что-то напоминающее самый первый подход.
Можно ещё покопать в сторону EMF, но я не в курсе, как там с интеграцией с базой данных. По той информации, что есть у меня, производительность DB->EMF оставляет желать лучшего.
Нереляционные ДБ это отдельная история, их используют либо в небольших, либо в очень больших приложениях. И в enterpise их не используют по той причине, что народ просто не шарит, как с ними работать.
Можно ещё покопать в сторону EMF, но я не в курсе, как там с интеграцией с базой данных. По той информации, что есть у меня, производительность DB->EMF оставляет желать лучшего.
Нереляционные ДБ это отдельная история, их используют либо в небольших, либо в очень больших приложениях. И в enterpise их не используют по той причине, что народ просто не шарит, как с ними работать.
Ну так это проблемы этого народа, нет?
Нет.
Когда вы пишите приложения для себя — используйте что хотите.
Но когда вы пишете в компании, то ваш API (в том числе, например, возможность использования SQL) будет использоваться другими людьми. Поэтому база данных с поддержкой SQL лучше, так как намного больше людей знает SQL.
Когда вы пишите приложения для себя — используйте что хотите.
Но когда вы пишете в компании, то ваш API (в том числе, например, возможность использования SQL) будет использоваться другими людьми. Поэтому база данных с поддержкой SQL лучше, так как намного больше людей знает SQL.
Намного больше людей знают PHP, чем Java. Давайте теперь не будем писать на Жаве?
Возможно, я просто рассуждаю с позиции lead'a в небольшой фирме, который и сам сотрудников нанимает, и сам технологии определяет.
Возможно, я просто рассуждаю с позиции lead'a в небольшой фирме, который и сам сотрудников нанимает, и сам технологии определяет.
Если бы стоимость разработки и поддержки решений на PHP была бы дешевле, чем на Java — использовали бы PHP. Рынок определяет.
Речь идёт, разумеется, про приложения уровня Enterprise, с большой разветвлённой структурой классов, где нужно взаимодействие RDBMS-AS-App-Client / External App. Разумеется, всё тоже можно сделать и на PHP, но стоить это будет дороже.
Сколько программистов могут написать MDB на Java? А его аналог на PHP? Теперь EJB с поддержкой XA транзакций (встроено в J2EE) и его аналог на PHP?
Речь идёт, разумеется, про приложения уровня Enterprise, с большой разветвлённой структурой классов, где нужно взаимодействие RDBMS-AS-App-Client / External App. Разумеется, всё тоже можно сделать и на PHP, но стоить это будет дороже.
Сколько программистов могут написать MDB на Java? А его аналог на PHP? Теперь EJB с поддержкой XA транзакций (встроено в J2EE) и его аналог на PHP?
Сейчас набежит толпа злобных PHP'шников и заминусует вам карму, готовьтесь:)
«Рынок определяет» — это когда вам заказчик прямым текстом говорит: «хочу такую-то программу на *таком-то* языке». А так определяют самые крикливые и(или) авторитетные разработчики у исполнителя.
Безусловно, я очень сильно утрирую и упрощаю.
ЗЫ: Я добавил коммент ниже. Посмотрите его тоже, пожалуйста.
ЗЗЫ: На всякий случай: мне интересно это обсуждение, и интересно ваше мнение как человека с другим взглядом. Возможно, мои комменты несколько остры, но таков уж я…
«Рынок определяет» — это когда вам заказчик прямым текстом говорит: «хочу такую-то программу на *таком-то* языке». А так определяют самые крикливые и(или) авторитетные разработчики у исполнителя.
Безусловно, я очень сильно утрирую и упрощаю.
ЗЫ: Я добавил коммент ниже. Посмотрите его тоже, пожалуйста.
ЗЗЫ: На всякий случай: мне интересно это обсуждение, и интересно ваше мнение как человека с другим взглядом. Возможно, мои комменты несколько остры, но таков уж я…
«Рынок определяет» — это ещё когда вы смотрите на прейскурант на специалистов и считаете:
— написать сайт на PHP — 1000 у.е.
— написать сайт на Java — 5000 у.е.
— написать приложение управления предприятием на Java — 10000 у.е.
— написать приложение управления предприятием на PHP — 50000 у.е.
тоже утрирую :)
— написать сайт на PHP — 1000 у.е.
— написать сайт на Java — 5000 у.е.
— написать приложение управления предприятием на Java — 10000 у.е.
— написать приложение управления предприятием на PHP — 50000 у.е.
тоже утрирую :)
Напишу чуть подробнее. На данный момент явно прослеживается тенденция ухода от реляционных баз. Оснований для этого очень много. Те, кто не хочет развиваться и учиться чему-то новому, останутся за бортом. Да, не быстро, но это произойдет рано или поздно.
Рассчитывать на подобных сотрудников может быть оправдано в финансовом плане, но, во-первых, это — насилие над собой (имхо), а, во-вторых, под вопросом остаются долгосрочные перспективы.
Поэтому если в процессе проектирования становится понятно, что схема базы будет часто меняться, то имеет смысл отказаться от привычного, к примеру, MySQL'a.
На самом деле меня задел ваш аргумент в стиле «миллион леммингов использует ...». Это можно назвать аргументом только после детального анализа ранка труда, плюсов и минусов разных решений, бюджета проекта, предположительных темпов развития и т.п… И это в любом это будет уникально для каждой отдельно взятой фирмы.
Рассчитывать на подобных сотрудников может быть оправдано в финансовом плане, но, во-первых, это — насилие над собой (имхо), а, во-вторых, под вопросом остаются долгосрочные перспективы.
Поэтому если в процессе проектирования становится понятно, что схема базы будет часто меняться, то имеет смысл отказаться от привычного, к примеру, MySQL'a.
На самом деле меня задел ваш аргумент в стиле «миллион леммингов использует ...». Это можно назвать аргументом только после детального анализа ранка труда, плюсов и минусов разных решений, бюджета проекта, предположительных темпов развития и т.п… И это в любом это будет уникально для каждой отдельно взятой фирмы.
К сожалению, в последние три года я занимался только коммерческой разработкой, которая довольно консервативна. Уход от реляционных баз данных для меня выражается лишь в рекламе сервисов от Amazon/Google (в том числе внутренних вроде bigtable). В остальном — и обучение будущих сотрудников, и предложения на рынке труда — пока что знание SQL является обязательным, а строчки о нереляционных СУБД мало где увидишь.
Что касается «отказаться от», мне кажется, пока что нет достойных конкурентов реляционным базам данных, которые уже сейчас бы поддерживались на уровне платформ — .NET/J2EE. Под поддержкой я понимаю не просто возможность работать с СУБД, а поддержка самой идеологии в стандартах и шаблонах проектирования. Более того, я вижу некоторые теоретические ограничения в производительности, по которым РСУБД всегда будет обгонять СУБД вроде распределённых хеш-таблиц (например, поиск по определённым индексам).
«в любом это будет уникально» — это уникально для отдельной фирмы, но не для отрасли в целом. Пока что Enterprise — это либо .NET / Axapta, либо Java / SAP, либо 1С / Парус / etc, но PHP — единицы.
books.google.ru/books?id=FyWZt5DdvFkC — Java + .NET, PHP — лишь для уровня отображения
Ах да. Вообще-то самый популярный язык для Enterprise пока что был и остаётся… Cobol
Что касается «отказаться от», мне кажется, пока что нет достойных конкурентов реляционным базам данных, которые уже сейчас бы поддерживались на уровне платформ — .NET/J2EE. Под поддержкой я понимаю не просто возможность работать с СУБД, а поддержка самой идеологии в стандартах и шаблонах проектирования. Более того, я вижу некоторые теоретические ограничения в производительности, по которым РСУБД всегда будет обгонять СУБД вроде распределённых хеш-таблиц (например, поиск по определённым индексам).
«в любом это будет уникально» — это уникально для отдельной фирмы, но не для отрасли в целом. Пока что Enterprise — это либо .NET / Axapta, либо Java / SAP, либо 1С / Парус / etc, но PHP — единицы.
books.google.ru/books?id=FyWZt5DdvFkC — Java + .NET, PHP — лишь для уровня отображения
Ах да. Вообще-то самый популярный язык для Enterprise пока что был и остаётся… Cobol
Где наблюдается? В вебе?
имеется схожая с идеалом автора логика работы:
на данный момент имеется следующая реализация:
описание типов — хранится в БД, т.е. какие типы
на данный момент имеется следующая реализация:
описание типов — хранится в БД, т.е. какие типы
хабр съел мое предложение не дождавшись окончания его написания, еще раз:
имеется схожая с идеалом автора логика работы:
описание типов — хранится в БД, исходя из описания формируются Java классы, далее эти классы уходят в Hibernate, который в свою очередь создает соответствующие классам таблицы. При изменении полей типа, автоматически на лету пересоздаются классы и перегружается SessionFactoryBean, что приводит к нужным изменениям в БД.
имеется схожая с идеалом автора логика работы:
описание типов — хранится в БД, исходя из описания формируются Java классы, далее эти классы уходят в Hibernate, который в свою очередь создает соответствующие классам таблицы. При изменении полей типа, автоматически на лету пересоздаются классы и перегружается SessionFactoryBean, что приводит к нужным изменениям в БД.
Имеется где? :)
имеется в основе этого сервиса, и конкретно в основе этого метода.
обратите внимание что есть возможность использовать комплексные типы, т.е. ссылки на уже ранее определенные типы
обратите внимание что есть возможность использовать комплексные типы, т.е. ссылки на уже ранее определенные типы
кстати а зачем XML Schema, можно ведь обойтись Annotations
Annotations — они внутри кода. А нужно средство описания структуры данных, которое можно исменять в runtime.
XML Schema тут ещё не только как физический способ хранения, но и как отправная точка. Например, в XML Schema нет элементарного типа «enum» — это предикат более простого типа string/int. Аналогично, в XML Schema множественность значения (multiple) — также предикат. Наличие подобной проработанной модели мета-данных сильно помогает.
XML Schema тут ещё не только как физический способ хранения, но и как отправная точка. Например, в XML Schema нет элементарного типа «enum» — это предикат более простого типа string/int. Аналогично, в XML Schema множественность значения (multiple) — также предикат. Наличие подобной проработанной модели мета-данных сильно помогает.
описание структуры данных проще хранить в БД в специальных описательных таблицах, а из них в runtime режиме уже генерить код с анотациями
А формат этих таблиц? :)
Вот задашься неправильной структурой (вроде multiple как отдельный тип) и будешь мучаться лет 15…
Вот задашься неправильной структурой (вроде multiple как отдельный тип) и будешь мучаться лет 15…
так а что спасет если также задаться неправильной структурой в XML?
в добавок определение типов проходит через специальные методы, не руками, все автоматизировать, тогда вероятность ошибки стремится к 0.
в добавок определение типов проходит через специальные методы, не руками, все автоматизировать, тогда вероятность ошибки стремится к 0.
Я немножко о другом. О формате мета-таблиц. Какие типы атрибутов запланировать, как сделать флаги read only / fixed / multiple / etc.
В формате XML Schema это уже хорошо расписано. Что, например, multiple является предикатом, default value — мета-аттрибутом аттрибута, а enum — это подтип другого типа.
А в одной известной мне системе enum является отдельным типом, но не наследуемым, в результате — некоторые проблемы со структурой данных, отсутствие некоторых unique ключей и т.д. В другой системе multiple является отдельным типом и только строковым — тоже не самое хорошее ограничение.
В формате XML Schema это уже хорошо расписано. Что, например, multiple является предикатом, default value — мета-аттрибутом аттрибута, а enum — это подтип другого типа.
А в одной известной мне системе enum является отдельным типом, но не наследуемым, в результате — некоторые проблемы со структурой данных, отсутствие некоторых unique ключей и т.д. В другой системе multiple является отдельным типом и только строковым — тоже не самое хорошее ограничение.
А мы кстати используем что то подобное. Но метаданные как известно есть и в самой БД. Но мы не используем типизированный подход. С одной стороны айс, вообще не надо писать новый код для новой таблицы, никакой генерации и т.д. С другой стороны хреново что подход не типизированный, все таки добавляются определенные сложности разработки… Модель классов отвечающих за работу с БД похожа на модель ADO.Net, но со своими рюшечками.
Очень интересно будет посмотреть на то, что у вас получилось. А я может покажу что получилось у нас. :-)
Очень интересно будет посмотреть на то, что у вас получилось. А я может покажу что получилось у нас. :-)
Вы знаете про EAV/CR — en.wikipedia.org/wiki/Entity-attribute-value_model? Как я понимаю, под форматом с метаданными вы имеете в виду именно это
Sign up to leave a comment.
Мета-данные. На пути к идеалам управления моделями данных