Здравствуйте, Дарней, Вы писали:

Д>В чем здесь неразрешимая проблема то?
О неразрешимих проблемах никто не говорит.
Но, как минимум, проблемы в том, что часть данных нужная одной декомпозиции не доступна из другой. Иными словами, для того чтобы любая возможная "декомпозиция", получила доступ ко всем данным, основная "декомпозиция", в которую обернуты данные, должна давать доступ ко всем данным, а это уже не совсем ООП.
Далее, эта самая основная "декомпозиция" работает с данными ограниченным набором методов, и гарантии что это набор методов будет подходить оптимальным образом для всех "декомпозиций" уровнем выше — никто не даст. Следовательно, либо эта самая основная "декомпозиция" должна знать обо всех "декомпозициях" более высокого уровня, что есть нонсенс, либо придется городить дополнительную прослойку оберток и адаптеров.
Можно так работать? — можно. Удобно? — нет. Об этом и речь.

Д>В чем конкретно будут заключаться различия этих декомпозиций?
В том что им нужны разные данные.

Д>если у тебя есть в этом сомнения, приведи конкретные примеры задач, которые ну никак не ложатся на объекты.
Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.

Д> А то меня что-то уже слегка мутит от общих слов.
Никто не неволит...

Д>а где там вообще вопрос?
Ну хватит дурака включать...

Здравствуйте, shuklin, Вы писали:

S>Сетевая модель, в отличии от иерархической (для иерархической ОМД все твои замечания действительно полностью адекватны) позволяет представлять один и тот же элемент данных одновременно в разных декомпозициях.
Как уже было замечено, речь здесь не о сетевой модели, а об ООП.

S> И кстати, и в отличии от РМД в которой все данные жестко прибиты к кортежам.
В отличии от реляционки, для того чтобы представить данные в новой декомпозиции, сетевой БД необходимо явно прописать эти связи в БД, в противном случае сетевая БД ничем не лучше иерархической.

S>И в этом случае РМД + РБД отдыхают по сравнению с сетевыми ОМД/ОБД.
Про розовые очки там было очень метко сказано...

Здравствуйте, Дарней, Вы писали:

Д>Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?

Не в ООП, а сам(а,о) ООП.

IT>>Самодостаточная персистентная распределённая объектная модель мира — это утопия.

Д>А знаешь, где здесь заключается утопия? В словах "модель мира". Всё остально — вторично.

Думаешь? Давай возьмём в качестве примера интернет. Чем тебе не модель мира, вот где глобализму хоть отбавляй. И ведь работает, и не утопия, но основан не на ООП, хотя где-то местами ООП безусловно с успехом используется.

Здравствуйте, GlebZ, Вы писали:

GZ>А кто сказал что в распределенной среде ООБД плохо живется?

А кто сказал что хорошо?

Здравствуйте, Merle, Вы писали:

M>О неразрешимих проблемах никто не говорит.

значит, про закат ООП было сказано для красного словца?

M>Но, как минимум, проблемы в том, что часть данных нужная одной декомпозиции не доступна из другой. Иными словами, для того чтобы любая возможная "декомпозиция", получила доступ ко всем данным, основная "декомпозиция", в которую обернуты данные, должна давать доступ ко всем данным, а это уже не совсем ООП.

приведи хоть один конкретный пример, который иллюстрирует твои тезисы, тогда и обсудим. А то продираться через нагромождения слов и пытаться воспроизвести ход твоих мыслей я уже устал.

M>Далее, эта самая основная "декомпозиция" работает с данными ограниченным набором методов, и гарантии что это набор методов будет подходить оптимальным образом для всех "декомпозиций" уровнем выше — никто не даст. Следовательно, либо эта самая основная "декомпозиция" должна знать обо всех "декомпозициях" более высокого уровня, что есть нонсенс, либо придется городить дополнительную прослойку оберток и адаптеров.

либо нужно подумать о том, что интерфейс объектов может меняться с изменением требований к системе. Свежая мысль, не правда ли?
Спроектировать объектную модель классов, "шоб всегда само работало", все равно никогда не получится.

M>Во-первых, не "ну никак", а плохо, а во-вторых, уже приводил. Персистентность, распределенка, отчетность.

персистентность? вау, как интересно! а мужики то и не знают (С)
распределенка? а здесь то вообще какие проблемы?
отчетность, точнее агрегирование данных — это да, некоторые проблемы здесь есть. Но всё тоже можно решить при наличии желания.

Д>> А то меня что-то уже слегка мутит от общих слов.
M>Никто не неволит...

то есть конкретных примеров так и не будет?

M>Ну хватит дурака включать...

просто формулируй мысли по человечески

Здравствуйте, shuklin, Вы писали:

S>>>- инкапсуляция не рекомендуется к применению.
S>>>- для особых случаев допускается бинарная сериализация ЧАСТИ объекта.

IT>>Это уже не OODB, а COODB, где C абревиатура от castrated. Это как раз то о чём говорит Иван, получается ни два, ни полтора. Кастрированная объектная модель и такая же неполноценная база данных.

S>И что же такого важного я не смогу провернуть в такой модели, что можно провернуть в вашей?

Ты же сам перечислил свои ограничения Ты не можешь в полной мере использовать инкапсуляцию, т.е. один из трёх китов ООП ты уже скаплелёчком чик и отрезал. А как же внутреннее состояние объекта. Жесткие требования к сериализации как я понимаю тоже из этой серии. То что будет сериализоваться будет лежать в базе просто как блоб, поиска по этим данных мы не получим.

Твои объекты это фактически примитивные DTO без инкапсуляции и внутреннего состояния.

S>Как раз наоборот. Это вы в своей "полной" модели не сможете сделать многого что я смогу сделать в своей "castrated"

У меня в моей модели нет никаких искусственных ограничений. Вообще никаких. Данные лежат отдельно и обрабатываются специально для этого годами затачиваемыми средствами. А объектная модель во всей своей красе и со всеми своими целыми не насильно отрубленными причиндалами отдельно.

S>Поэтому считаю ваши доводы неубедительной демагогией.

Вот уж чья бы корово мукала насчёт неубедительной демагогии, а втоя бы лучше за собой последила. Пока кроме эмоций от тебя никаких убедительных аргументов не последовало. А аргументы и доказательства состоятельности своей позиции надо приводить как раз тебе, т.к. сегодня по истечении более десяти лет все попытки сделать OODB так и остались попытками.

S>И на маппинг там время не тратится, и сети поддерживаются по полной, Ну ну.

Время на маппинг вполне сравнимо с сериализацией объектов из твоей ООБД.

Здравствуйте, Merle, Вы писали:

M>С моей точки зрения честная ООБД — это та, которая поддерживает, как минимум, наследоване, инкапсуляцию и полиморфизм, в том виде, в котором ее поддерживают современные объектные ЯП.

для начала давай уточним, какие из современных ЯП?

к тому же наследование — далеко не обязательный пункт
фактически, для соответствия ООП требуется всего два пункта — инкапсуляция и полиморфизм (полиморфизм != virtual method). Механизм расширения объектов (опять таки != наследованию) — желателен, но не обязателен.

Здравствуйте, IT, Вы писали:

Д>>Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?

IT>Не в ООП, а сам(а,о) ООП.

неважно. Хочу точные данные

Д>>А знаешь, где здесь заключается утопия? В словах "модель мира". Всё остально — вторично.

IT>Думаешь? Давай возьмём в качестве примера интернет. Чем тебе не модель мира, вот где глобализму хоть отбавляй. И ведь работает, и не утопия, но основан не на ООП, хотя где-то местами ООП безусловно с успехом используется.

ну во первых, если интернет — модель, то давай уточним кое-какие вопросы.
Какие аспекты мира он моделирует, какие — нет? Иными словами, насколько полна эта модель?
Каким задачам она служит?

Во вторых, основа интернета — гипертекст — это все равно ООП в чистом виде

Здравствуйте, Дарней, Вы писали:

Д>значит, про закат ООП было сказано для красного словца?
Откуда такой вывод?

Д>приведи хоть один конкретный пример, который иллюстрирует твои тезисы, тогда и обсудим.
Учись мыслить абстрактно..

Д> А то продираться через нагромождения слов и пытаться воспроизвести ход твоих мыслей я уже устал.
Никто не неволит.

Д>либо нужно подумать о том, что интерфейс объектов может меняться с изменением требований к системе. Свежая мысль, не правда ли?
Угу, то есть каждый раз при изменении задачи, переделывать базовые объекты, хотя сами данные не менялись — действительно свежо.

Д>Спроектировать объектную модель классов, "шоб всегда само работало", все равно никогда не получится.
Именно, об этом и речь. Так зачем ее проектировать, если можно хранить сырые данные и накручивать поверх нужные объекты в случае необходимости?

Д>персистентность? вау, как интересно! а мужики то и не знают (С)
Не знаю, что там не знают мужики, а вот проблемы с сохранением объектов сложно не заметить. Добро пожаловать мужикам в реальный мир.

Д>распределенка? а здесь то вообще какие проблемы?
Ну ка — ну ка, как там мужики объекты и вызовы по сети гоняют? В лучшем случае DTO... Это называется — нет проблем?

Д>отчетность, точнее агрегирование данных — это да, некоторые проблемы здесь есть.
То есть, когда ты говорил, что проблем нет — обманывал?

Д>Но всё тоже можно решить при наличии желания.
А кто говорил, что ничего решить нельзя? Просто есть более адекватные способы, чем пытаться сделать все через объекты.

Д>то есть конкретных примеров так и не будет?
Да куда уж конкретнее, все же разжевал, а то что примеры тебя не устраивают, так я не виноват.

Д>просто формулируй мысли по человечески
И так уж человечнее некуда.

Здравствуйте, Дарней, Вы писали:

Д>>>Я все-таки так и не понял, что именно в ООП плохо работает и при каких условиях?
IT>>Не в ООП, а сам(а,о) ООП.
Д>неважно. Хочу точные данные

Точные данные чего? Того что ООП не работает в распределённых системах и в ООБД? Ты понимаешь в чём дело, если нет таких данных, то они никак не могут быть точными. Есть данных, что где-то кто-то когда-то от кого-то слышал или даже видел глазами расказчика про то, что ООП вдруг успешно применился в суперраспределённой среде и ООБД. По таким слухам сложно собрать точные данные, так что извини

Д>ну во первых, если интернет — модель, то давай уточним кое-какие вопросы.
Д>Какие аспекты мира он моделирует, какие — нет? Иными словами, насколько полна эта модель?
Д>Каким задачам она служит?

Интернет — это глобальная распределённая сеть. И глобальная и распределённая, т.е. то о чём ООП может только продолжать мечтать. И заметь, это работает и ни мне ни тебе это не надо доказывать. Мы оба знаем что это так.

Д>Во вторых, основа интернета — гипертекст — это все равно ООП в чистом виде

Точно так же можно сказать, что основа ООП — это машинные коды. Впрочем, я с этим спорить не собираюсь. Как я уже сказал, ООП прекрасно себя чувствует на небольших модельках, где может и должен эффективно применяться. Но только не надо глобализму, и всё у нас получится

Здравствуйте, GlebZ, Вы писали:

GZ>Мое IMHO что эпоха ООБД еще не начиналась.

Эта эпоха может начаться только когда закончится эпоха написания кода человеком. Для человека это слишком сложная задача.

Здравствуйте, AndrewVK, Вы писали:

GZ>>Что значит привинчен?
AVK>То и значит, что в ООБД данные неразрывно связаны с кодом.
Вообще-то наоборот, и зависит от типа OODB. Фактически существует два типа OODB — пассивные, и активные. Пассивные, типа того-же Versant, отличаются от OODB+ORM мало. Единственное, что хранилище максимально приспособлено под навигационный доступ. Декларативные запросы идут не по объектам, а именно по данным. Активные, типа GemStone более объектные и полностью инкапсулируют данные. Правда иногда все равно эту инкапсуляцию нарушают на уровне запросов(к сожалению не спец по ней, сужу по рассказам).
Основная проблема того, что нарушается инкапсуляция — многоязычность и императивность языков. Запрос должен быть переформирован в форму которая должна быть максимально селективна. Для императива, в котором может быть написано все что угодно, из кода которого иногда просто невозможно получить граф это принципиально невозможно. Microsoft поступил проще введя лямбды. Возможно под это дело появятся новые ODB.

Здравствуйте, Merle, Вы писали:

M>Откуда такой вывод?

ну ты уж определись хотя бы. Или есть непреодолимые проблемы, и тогда ООП действительно ничего хорошего не светит, или их нет.

M>Учись мыслить абстрактно..

излагать неясно запутанные мысли != мыслить абстрактно
если ты не в состоянии сгенерировать простой и ясный пример, который иллюстрирует твои абстракции — значит, никаких абстракций у тебя просто нет
хинт — говорить "Х не работает, потому что я так сказал" за пример проблемы не засчитывается

Д>> А то продираться через нагромождения слов и пытаться воспроизвести ход твоих мыслей я уже устал.
M>Никто не неволит.

я еще не оставил надежду, что за твоими словами есть какой-то смысл

M>Угу, то есть каждый раз при изменении задачи, переделывать базовые объекты, хотя сами данные не менялись — действительно свежо.

объект — это совокупность данных и методов, которые их обрабатывают в соответствии с требованиями. Если требования меняются, то меняются и методы. Тебя в этом что-то удивляет?

Д>>Спроектировать объектную модель классов, "шоб всегда само работало", все равно никогда не получится.
M>Именно, об этом и речь. Так зачем ее проектировать, если можно хранить сырые данные и накручивать поверх нужные объекты в случае необходимости?

сырые данные и так всегда есть. Внутри объектов. Зачем создавать дополнительное представление данных?

M>Не знаю, что там не знают мужики, а вот проблемы с сохранением объектов сложно не заметить. Добро пожаловать мужикам в реальный мир.

с каким конкретно сохранением? Сериализацией в файл? Маппингом объектов на РБД? Сохранением объектов в ОБД? Какую конкретно из них? Какие конкретно проблемы?

M>Ну ка — ну ка, как там мужики объекты и вызовы по сети гоняют? В лучшем случае DTO... Это называется — нет проблем?

У объекта есть данные, их упаковывают, пересылают на другую сторону и создают точно такой же объект. Где ты здесь видишь проблему?

Д>>отчетность, точнее агрегирование данных — это да, некоторые проблемы здесь есть.
M>То есть, когда ты говорил, что проблем нет — обманывал?

проблемы есть, но они есть у существующих реализаций ОБД и существующих реализаций языков. Мы здесь обсуждаем перспективу, не так ли?

M>А кто говорил, что ничего решить нельзя? Просто есть более адекватные способы, чем пытаться сделать все через объекты.

какие? ORM, что ли?

Д>>то есть конкретных примеров так и не будет?
M>Да куда уж конкретнее, все же разжевал, а то что примеры тебя не устраивают, так я не виноват.

я пока еще ни одного не видел, поэтому судить пока не могу

Д>>просто формулируй мысли по человечески
M>И так уж человечнее некуда.

тогда мне даже страшно представить, что будет, если ты включишь генератор флейма

Здравствуйте, IT, Вы писали:

GZ>>А кто сказал что в распределенной среде ООБД плохо живется?
IT>А кто сказал что хорошо?
Можешь верить или не верить но именно отчеты и распределенки лучше всего уживаются в распределенной среде по сравнению с чистой реляционкой.
Для реляционки репорты являются проблемой из-за двухмерности. Не зря Кодд придумал OLAP. Вторая проблема в том, что очень сложно обрабатывать сложные случаи типа "если у нас такая сумма, то мы берем следующий коэффициент и по нему высчитываем сумму". Навигационный доступ с ручной обработкой в данном случае более удобен.
Что касается распределенной среды, то распределенность изначально закладывалась в OID. Когда есть OID у тебя нет дубликатов ключей при репликации как понятия. OID может адресовать не строку в базе, а объект находящийся вообще на другом компе. Во многом, подобная распределенность сделана в GemStone. В ней граф объектов может быть и локальным, и удаленным.(некоторые потуги Oracle по кэшированию локальных данных появились только сейчас).

Здравствуйте, IT, Вы писали:

IT>Эта эпоха может начаться только когда закончится эпоха написания кода человеком. Для человека это слишком сложная задача.
Скорее немного не так. Когда машина начнет понимать что человек написал. А DLinq уже может интерпретировать и трансформировать такой код. Так что эпоха не начинается, а можно сказать наступила.

Здравствуйте, shuklin, Вы писали:

S>Здравствуйте, Merle, Вы писали:

S>>>Ваши доводы или совершенно неубедительны,
M>>Аргументы кончились? Не нравится — не ешь..

S>Извините, но у Вас я вообще аргументов не заметил. Только декларацию того что ОБД это бесперспективно. "Не нравится — не ешь.. "

S>Ну не любишь ты ОБД, а я не люблю РБД хоть и работаю с РБД каждый день, и каждый день по сравнению со своей БД не люблю SQL все больше и больше . Знаешь, мне с тобой беседовать просто скушно. Ничего нового ты не пишешь, только твердишь что ОБД — фигня. Ни на один мой тезис о внутреннем устройсве Cerebrum ты не ответил. Ни о синонимии/омонимии идентификаторов, ни о структурном полиморфизме ... Какие еще аргументы? , ты б в старые врубился хоть Так. С вами я флейм заканчиваю. Меняйте ник и стиль общения. Жалко на такое время тратить.

Merle тебя разводит по понятиям.
Базданщики это такая кагорта программеров, которые так любили стратигическое планирование, что съели много дерьма пока проектировали свои базы. Теперь это дерьмо лезет наружу. Это выражается в снобизме на понятиях. Прямо как в академии наук. Они убеждены в том, что если ты не ел тогоже дерьма то и ничего хорошего сделать не сможешь. И нечего смотреть на твои поделки. Ты в их глазах — безграмотный самоучка, выскочка. Над которым можно разве что поглумиться.
Merle, ничего личного. Это просто психология и национальное самосознание такие.

А вам, shuklin — совет. Ищите спонсора среди буржуев. У нас в россии не принято делать из человека икону при жизни.
Вот когда сдохнет — пожалуйста.
А так мы в россии всяких надоедливых самоучек-выскочек только травим да глумимся над ними.

Здравствуйте, Merle, Вы писали:


S>>Может пост прозевал. Приведешь ссылку?
M>Легко: Re: Файловые системы, файлы, приложения — устаревшие концепц

Автор: Merle
Дата: 20.04.06

Это я ужо читал. В натуре не убеждает. Ну ни на чуть чуть. Может вы и правы в чемто, но по этому посту я этого не вижу.

Здравствуйте, shuklin, Вы писали:

S>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта. Волновой алгоритм пропагации изменений это обеспечит с минимальными затратами перформанса (в Cerebrum еще не реализовано.)
Кхм. А что такое "волновой алгоритм пропагации"? Гугл на запросы типа "wave index/tree/map propagation" выдает левые ссылки.

Волновой алгоритм нахождения кратчайшего пути — я знаю. А вот как он относится к индексам?

S>4. Мы тут не столько мое изделие обсждаем сколько ваще ОБД против ваще РБД. Я свою БД привожу в пример в тех случаях, когда я уже реализовал то что вы объявляете невозможным.
Интересны базовые алгоритмы — они определяют скорость работы. У вас есть что-то новое, чего нет в существующих ОО/РБД?

S>5. Это у тебя с полиморфизмом какойто детский комплекс его якобы необходимости для ОБД во всех случаях? Когда нужен ОБД должна позволять его реализовать. Когда не нужен — должна позволить проиндексировать поле объекта в стиле РБД. Какие проблемы? Выбор у разработчика.
Если нет полиморфизма, то ОО "легким движением руки" превращается в РБД.

Наследование реализуется в виде join'ов, а инкапсюляция — с помощью прикладных средств работы с БД. Даже навигационный доступ нормально работает в ORM (см. http://www.hibernate.org ).Что у вас есть принципиально нового?

S>Итак и по этому пункту ОБД по крайней мере не хуже РБД во всех возможных сценариях. Во многих — лучше и мощнее.
Отличительная особенность ООБД — навигационный доступ. Благодаря нему можно легко обрабатывать сложносвязные данные, но как раз навигационный доступ мешает построению индексов.

ЗЫ: кстати, а Reiser4 смотрели? Там у них построена FS поверх с поддержкой построения индексов по заданным пользователем критериям (фактически, туда добавить еще движок SQL и будет готовая база), причем FS вполне резво работает на миллионах файлов в одном каталоге. Вот тут я приводил простой benchmark: http://rsdn.ru/Forum/Message.aspx?mid=1710544&only=1

Автор: Cyberax
Дата: 02.03.06

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, shuklin, Вы писали:

S>>>>- инкапсуляция не рекомендуется к применению.

IT>Ты же сам перечислил свои ограничения Ты не можешь в полной мере использовать инкапсуляцию,
Я уже устал отвечать на этот вопрос одно и тоже. Не рекомендую — не значит не могу. Могу. Но инкапсуляция в том виде в котором она есть в обычном языке программирования в БД лишня. Она лишняя в РБД. Она лишняя в ОБД, Не нужна там такая концепция. Лишняя концепция не значит нереализуемая или неподдреживаемая. Я ее поддерживаю. Кто пользуется — принимает на себя следствия ее использования. Согласитесь, если сама концепция инкапсуляции просто по законам логики влечет за собой отрицательные последствия для БД — не зависимо от того ОБД или РБД — то наверное что то не с конкретной реализацией ОБД а с самой концепцией. Вот я и дал возможность — кому надо — пользоваться, кому не надо — не пользоваться.

IT>А как же внутреннее состояние объекта. Жесткие требования к сериализации как я понимаю тоже из этой серии. То что будет сериализоваться будет лежать в базе просто как блоб, поиска по этим данных мы не получим.

Тоже устал писать одно и тоже. Объект в моей БД можно сохранять частями. См. в соседних ветках.

IT>Вот уж чья бы корово мукала насчёт неубедительной демагогии, а втоя бы лучше за собой последила. Пока кроме эмоций от тебя никаких убедительных аргументов не последовало. А аргументы и доказательства состоятельности своей позиции надо приводить как раз тебе, т.к. сегодня по истечении более десяти лет все попытки сделать OODB так и остались попытками.

Знаете, для меня лучший аргумент — это работоспособный код который решает описанные проблемы. В соседних ветках уже есть гора сообщений с кратким описанием решений. Этот работоспособный код у меня есть, так что можете тут хоть лопнуть — мне это как бы без разницы.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, shuklin, Вы писали:

S>>3. Никто не мешает динамически обновлять индекс при изменении вычисляемого значения свойства объекта. Волновой алгоритм пропагации изменений это обеспечит с минимальными затратами перформанса (в Cerebrum еще не реализовано.)
C>Кхм. А что такое "волновой алгоритм пропагации"? Гугл на запросы типа "wave index/tree/map propagation" выдает левые ссылки.


От так я вам тут все свои ноу хау и выдал )) На данный момент из ноу хау реализована и опубликована новая версия идентификации экземпляров объектов, не совместимая с ODMG. Это я про синонимию и омонимию идентификаторов экземпляров объектов.


C>Интересны базовые алгоритмы — они определяют скорость работы. У вас есть что-то новое, чего нет в существующих ОО/РБД?

Ну вот идентификация другая. Дальше будет больше но не сразу. Не реализованные фичи я обсуждать не буду.


C>Если нет полиморфизма, то ОО "легким движением руки" превращается в РБД.

РБД это в первую очередь РМД. А вот моя ОБД лежит на сетевой МД. РБД она не может быть ну никак.

S>>Итак и по этому пункту ОБД по крайней мере не хуже РБД во всех возможных сценариях. Во многих — лучше и мощнее.
C>Отличительная особенность ООБД — навигационный доступ. Благодаря нему можно легко обрабатывать сложносвязные данные, но как раз навигационный доступ мешает построению индексов.

В РБД есть понятие буукмарк. Это и есть скрыты ОИД. Не понятно кому и чем ОИД мешает, в ОБД если он не мешает в РБД,


C>ЗЫ: кстати, а Reiser4 смотрели? Там у них построена FS поверх с поддержкой построения индексов по заданным пользователем критериям (фактически, туда добавить еще движок SQL и будет готовая база), причем FS вполне резво работает на миллионах файлов в одном каталоге. Вот тут я приводил простой benchmark: http://rsdn.ru/Forum/Message.aspx?mid=1710544&only=1

Автор: Cyberax
Дата: 02.03.06

Неа, на это дело не глядел. Будет время — обязательно погляжу.