Исправление DRVTiny, (текущая версия) :
Перечисли список практических задач, которые решает (L)DAP
Вообще LDAP как протокол и как методология не решает никаких задач, кроме тупо задачи организации хранения данных.
Благодаря таким особенностям LDAP как жёсткая стандартизация формата, структурированность (то есть это не «макароны» традиционной реляционной СУБД) по принципу иерархии, развитые возможности распределённого/«разделённого» хранения и репликации (до которых всем SQL ещё расти и расти) LDAP подходит для весьма широкого круга задач. Главным образом, это задачи, предусматривающие доступ множества различных приложений к одним и тем же консолидированным и существенно чаще читаемым, чем записываемым, данным. Почему именно множества приложений? Потому что ключевая особенность, отличающая мир LDAP от мира реляционных СУБД - это всё-таки стандартизация. Та самая стандартизация, на которой вообще зиждется мир web-технологий. И сам по себе LDAP ориентирован на более «глобальное» применение, чем реляционные СУБД, потому что если построенной в одной компании базой данных с высосанными из пальца именами таблиц, столбцов и взаимосвязей между таблицами могут пользоваться только специализированные приложения, написанные в данной компании, то LDAP-каталог - это как веб-страница в Интернет, которую должны уметь прочитать и верно интерпретировать все.
Ну и да, как бы вы ни сетовали на философию, но всё-таки принцип «все собственные данные объекты хранятся в одной записи, представляющей этот объект в Каталоге» (принцип инкапсуляции данных) - ключевая концепция LDAP, её краеугольный камень. Так же, как и стандартизация attributeTypes/objectClasses/matchingRules, etc. Люди, которые не понимают этих вещей, часто строят собственные костыльные каталоги с выдуманными по настроению именами атрибутов, учётными записями Васи Пупкина в 10 различных ветках и прочими подобными чудесами, которые по сути просто сводят на нет львиную долю преимуществ использования именно этой методологии, а не тех же реляционных СУБД с их тотальной демократией, доходящей до того, что даже сам язык запросов в разных СУБД может сильно различаться.
Исправление DRVTiny, :
Перечисли список практических задач, которые решает (L)DAP
Вообще LDAP как протокол и как методология не решает никаких задач, кроме тупо задачи организации хранения данных.
Благодаря таким особенностям LDAP как жёсткая стандартизация формата, структурированность (то есть это не «макароны» традиционной реляционной СУБД) по принципу иерархии, развитые возможности распределённого хранения и репликации (до которых всем SQL ещё расти и расти) LDAP подходит для весьма широкого круга задач. Главным образом, это задачи, предусматривающие доступ множества различных приложений к одним и тем же консолидированным и существенно чаще читаемым, чем записываемым, данным. Почему именно множества приложений? Потому что ключевая особенность, отличающая мир LDAP от мира реляционных СУБД - это всё-таки стандартизация. Та самая стандартизация, на которой вообще зиждется мир web-технологий. И сам по себе LDAP ориентирован на более «глобальное» применение, чем реляционные СУБД, потому что если построенной в одной компании базой данных с высосанными из пальца именами таблиц, столбцов и взаимосвязей между таблицами могут пользоваться только специализированные приложения, написанные в данной компании, то LDAP-каталог - это как веб-страница в Интернет, которую должны уметь прочитать и верно интерпретировать все.
Ну и да, как бы вы ни сетовали на философию, но всё-таки принцип «все собственные данные объекты хранятся в одной записи, представляющей этот объект в Каталоге» (принцип инкапсуляции данных) - ключевая концепция LDAP, её краеугольный камень. Так же, как и стандартизация attributeTypes/objectClasses/matchingRules, etc. Люди, которые не понимают этих вещей, часто строят собственные костыльные каталоги с выдуманными по настроению именами атрибутов, учётными записями Васи Пупкина в 10 различных ветках и прочими подобными чудесами, которые по сути просто сводят на нет львиную долю преимуществ использования именно этой методологии, а не тех же реляционных СУБД с их тотальной демократией, доходящей до того, что даже сам язык запросов в разных СУБД может сильно различаться.
Исправление DRVTiny, :
Перечисли список практических задач, которые решает (L)DAP
Вообще LDAP как протокол и как методология не решает никаких задач, кроме тупо задачи организации хранения данных.
Благодаря таким особенностям LDAP как жёсткая стандартизация формата, структурированность (то есть это не «макароны» традиционной реляционной СУБД) по принципу иерархии, развитые возможности распределённого хранения и репликации (до которых всем SQL ещё расти и расти) LDAP подходит для весьма широкого круга задач. Главным образом, это задачи, предусматривающие доступ множества различных приложений к одним и тем же консолидированным и существенно чаще читаемым, чем записываемым, данным. Почему именно множества приложений? Потому что ключевая особенность, отличающая мир LDAP от мира реляционных СУБД - это всё-таки стандартизация. Та самая стандартизация, на которой вообще зиждется мир web-технологий. И сам по себе LDAP ориентирован на более «глобальное» применение, чем реляционные СУБД, потому что если построенной в одной компании базой данных с высосанными из пальца именами таблиц, столбцов и взаимосвязей между таблицами могут пользоваться только специализированные приложения, написанные в данной компании, то LDAP-каталог - это как веб-страница в Интернет, которую должны уметь прочитать и верно интерпретировать все.
Ну и да, как бы вы ни сетовали на философию, но всё-таки принцип «все собственные данные объекты хранятся в одной записи, представляющей этот объект в Каталоге» (принцип инкапсуляции данных) - ключевая концепция LDAP, её краеугольный камень. Так же, как и стандартизация attributTypes/objectClasses/matchingRules, etc. Люди, которые не понимают этих вещей, часто строят собственные костыльные каталоги с выдуманными по настроению именами атрибутов, учётными записями Васи Пупкина в 10 различных ветках и прочими подобными чудесами, которые по сути просто сводят на нет львиную долю преимуществ использования именно этой методологии, а не тех же реляционных СУБД с их тотальной демократией, доходящей до того, что даже сам язык запросов в разных СУБД может сильно различаться.
Исходная версия DRVTiny, :
Перечисли список практических задач, которые решает (L)DAP
Вообще LDAP как протокол и как методология не решает никаких задач, кроме тупо задачи организации хранения данных.
Благодаря таким особенностям LDAP как жёсткая стандартизация формата, структурированность (то есть это не «макароны» традиционной реляционной СУБД) по принципу иерархии, развитые возможности распределённого хранения и репликации (до которых всем SQL ещё расти и расти) LDAP подходит для весьма широкого круга задач. Главным образом, это задачи, предусматривающие доступ множества различных приложений к одним и тем же консолидированным и существенно чаще читаемым, чем записываемым, данным. Почему именно множества приложений? Потому что ключевая особенность, отличающая мир LDAP от мира реляционных СУБД - это всё-таки стандартизация. Та самая стандартизация, на которой вообще зиждется мир web-технологий. И сам по себе LDAP ориентирован на более «глобальное» применение, чем реляционные СУБД, потому что если построенной в одной компании базой данных с высосанными из пальца именами таблиц, столбцов и взаимосвязей между таблицами могут пользоваться только специализированные приложения, написанные в данной компании, то LDAP-каталог - это как веб-страница в Интернет, которую должны уметь прочитать и верно интерпретировать все.
Ну и да, как бы вы ни сетовали на философию, но всё-таки принцип «все собственные данные об объекте хранятся в одной записи, представляющей этот объект» - ключевая концепция LDAP, её краеугольный камень. Так же, как и стандартизация attributTypes/objectClasses/matchingRules, etc. Люди, которые не понимают этих вещей, часто строят собственные костыльные каталоги с выдуманными по настроению именами атрибутов, учётными записями Васи Пупкина в 10 различных ветках и прочими подобными чудесами, которые по сути просто сводят на нет львиную долю преимуществ использования именно этой методологии, а не тех же реляционных СУБД с их тотальной демократией, доходящей до того, что даже сам язык запросов в разных СУБД может сильно различаться.