Некоторые новые функции MySQL не будут доступны в Community-версии

> Ну скажем через неделю (ну реально тормозит канал, хоть провайдеров режь).

уже. http://korrespondent.net/tech/technews/438061

капча buthers

> Моя нынешняя компания и предыдущая. Называть конечно не буду ибо нех :) В трудовом договоре написано: все сделанное в рабочее время есть собственность компании.

Я бы на месте твоей компании подал бы на ЛОР в суд за то, что тот без разрешения раздаёт на своём сайте собственность компании.

> уже. http://korrespondent.net/tech/technews/438061

Не знаю чо там по ссылке, но видимо как раз тот случай, который я и имел в виду.

>> Я как раз и говорил "для тех кто не владеет вопросом". Читайте доки.

> я всегда подозревал, что чрезмерное употребление mysql плохо отражается на организме. эти группы в нормальных rdbms называются data partitioning.

Повторяем... RTFM!!! есть data partitioning, а есть кластерный движок и группы в нем. Это разные вещи!

> M:N термины из той же реляционной базы. Нет никаких MN. Есть ссылки в памяти. Прямые. Ничего джойнить не надо все заджойнено до нас.

Отлично :) А теперь как вы на ссылках сделаете связь много-ко-много? Оба объекта будут иметь списки ссылок на другие? Тогда есть 2 списка данных и это означает, что рано или поздно они разъедутся! Нормальные формы для того и придуманы были ;)

> Создай на любом любимом языке программирования список польщзователей в которых будут прямые указатели на группы и т-д как ты захочешь.

У меня есть множество промежуточных объектов через которые идет связъ. Мне нужно получить набор опосредованно связанных данных. Пользователь напрямую не имеет ссылки на права, т.к. права от получает от групп в которые входит и изменение права группы АВТОМАТОМ отражаются на права пользователя. А у вас?

> Религиозные трудности - это религиозные трудности. Применяя ту или иную теорию (в данном случае реляционную алгебру или ее практическую реализацию RDBMS) полезно знать границы ее применимости а так же что она не является сильвер буллет - а всего лишь один из вариантов управления данными. Далеко не единственный.

Согласен, что не единственный вариант. Но поработав над созданием собственного движка данных на JavaScript понял что в большинстве задачь RDBMS рулеД.

> В su.softw вроде кто-то пару лет назад сказал "если проект длительностью пол года и более - стоит рассматривать возможность написаняия специализированной базы данных".

ХЗ. я тут соглашусь с другим оратором, сказавшим: у каждого приложениея есть срок жизни, НО базы данных БЕССМЕРТНЫ! Когда у вас десяток клиентов используют 30-40 серверов (разных версий), а их Одминят не наши админы а ихние. и они должны уметь делать бэкапы БД, настраивать производительность и т.п. Как они это будут делать на самописной поделке - не понятно.

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

> Особенности обоих в том что данные таковы что декомпозиция их в реляцонную модель - нетривиальна и объемна - проще хранить их как есть объектами - чем делать десятки/сотни таблиц - что удобнее для хранения и для синхронизации, и для миграции в следующих версиях.

> Сначала обе системы делались на реляционных базах - потом этот страшный сон был забыт. В результати получили вполне транзакцционные системы с ММR, которые по скорости интерфейсов вообще не заметны.

Если реляционная модель не подходит - нужно использовать другую. Тут соглашусь.

> Одна из фишек была в том что например для этой сетево системы много проблем решилось ничегонеделаньем, потому что проблемы эти существовали только, если база была реляционной. Как ты говоришь джойны и все такое. Вот не нужны они стали. И проблемы с репликацией перенеслись совсем в другую логику - вместо борьбы с referential integrity, констрейнтами и конфликтами, репликация стала атомарной, где атом - законченный логический кусок, а не "строки".

так что вместо джойнов? циклы через связанные данные? А на чем строится репликация? JMS? как разруливаются конфликты репликации?!?

> есть data partitioning, а есть кластерный движок и группы в нем. Это разные вещи!

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

> Повторяем... RTFM!!! есть data partitioning, а есть кластерный движок и группы в нем. Это разные вещи!

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

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

>А процитировать соответствующий пункт лицензии слабо? Или чукча не читатель чукча чужойбредповторятель?

Согласен, не CDDL, прямо, а SCA:

http://www.opensolaris.org/os/about/sun_contributor_agreement/

Led, так Ты оказуется жалкий балабол, разачарован...:(

Вот и я так думаю, что CDDL не имеет нечего общего с SCA или SLA, с которой нужно согласиться для использования Solaris 10...:)

>> M:N термины из той же реляционной базы. Нет никаких MN. Есть ссылки в памяти. Прямые. Ничего джойнить не надо все заджойнено до нас. > Отлично :) А теперь как вы на ссылках сделаете связь много-ко-много? Оба объекта будут иметь списки ссылок на другие? Тогда есть 2 списка данных и это означает, что рано или поздно они разъедутся! Нормальные формы для того и придуманы были ;)

Да вы просто религиозный тролль! Докажите что рано или поздно они разъедутся!

>> Отлично :) А теперь как вы на ссылках сделаете связь много-ко-много? Оба объекта будут иметь списки ссылок на другие? Тогда есть 2 списка данных и это означает, что рано или поздно они разъедутся! Нормальные формы для того и придуманы были ;)

>Да вы просто религиозный тролль! Докажите что рано или поздно они разъедутся!

В случае кластера очень просто: выпал узел, все ссылки на него пропали, когда поднялся - у него ни одной ссылки нет.

У него HA - на этом месте активизируется бэкап и ничего страшного не происходит.

>При этом внесение изменений в представление данных требует внесения изменений в структуру данных

Нет требует.

> (выше вы писали "Создай на любом любимом языке программирования список польщзователей.."),

И что? представление данных в виде дерева не менее общо чем представление в виде таблиц.

> что исключает как создание многоуровневой архитектуры (т.е. создания соттветствующих уровней абстракции),

Не исключает.

> так и возможность внесения изменений без полной остановки системы.

И корованы оно грабить не позволяет. Рассматривать изменение структуры без полной остановки системы - вообще смешно для серьезных систем. Для несерьезных - и такие решения есть.

>Что происходит? У вас две семьи создадутся или что?

Какое это имеет отношение к рассматриваемому вопросу? А в оракле сколько семей создадуться если 2 человека в разных репликах начнуть вводить данные? Решение ровно то же самое.

>Если как-то отслеживается уникальность - по номеру паспорта например, то как обойтись без транзакции?

А как это решиться в асинхронном MMR для любой rdbms? Да так же само!

Все ваши вопросы отношения к архитектуре базы данных отношения не имеют. ACID - совсем не уникальная фича RDBMS.

>Тут нет никакого выигрыша по сравнению с реляционной базой

Есть -более удобное представление данных, значительно большая скорость и т.д.

>И так на каждый пздох.

А в реляционной он завидится сам чтоли? Какой-то бред. Если вас просят грабить очередные корованы - что там у вас внизу отношения не имеет - все равно садись и делай - само не сделается.

>Только для того что бы избежать необходимости читать книжку "Эффективное использование РСУБД Х"?

Ради того чтобы писать более эффективные системы. Модете погуглить на тему async MMR в RDBMS - вы поймете что в области RDBMS эта задача из разряда стрельбы в ногу.

>значит нужно будет перебрать все записи и переделать структуру данных.

Мля ни надо ничего переделвать.

>Чем это решение лучше РСУБД?

Что такое foreign key? Это чертов разименованный указатель. Так вот - в моем случае данные имеют представление такое которое возникает для рдбмс толко в виде результатов выборки. То есть _результат уже есть_.

>Т.е. вы сравниваете аппликейшен сервер с сервером БД. А смысл в этом какой?

Ничего я не сравниваю. Вы что думаете что RDBMS это изобретение всех времен и народов, сделано на века и 100% преймущество везде или что? Вас окружают тучи специализированных баз данных - на вашем компьютере их стоит десятки.

>Видимо я пропустил этот ваш пост. И что, Postgres у них иерархический используется или что?

Нет - постгрес они используют "непоназначению" - в качестве партишенинга для параллельных запросов и столбцовых выборок (так они избегают скана строк - нету никаких строк.

>Видимо я пропустил этот ваш пост. И что, Postgres у них иерархический используется или что?

Я повторяю - это не кластер. Это сеть.

>и тут начинается всё самое интересное.

Самое интересное тут что самого интересного - не начинается.

>Синхронны ли будут данные в течение этой недели?

Конечно. Это не кластер и ноды не подставляются взамен друг друга.

>Не противоречивы ли они будут?

Непротиворечивы.

>А если в течение недели жулик снимет в офисе, пользующем ноду Г миллионы?

е может он ничего снять. Подобной логики в системе нет.

>Я имел в виду как вообще у вас обнаруживаются такие противоречивые транзакции?

Точно так же как в любой Async MMR системе. Никакая реляционная субд в природе не решит проблему конфликтов в Async MMR случае. Эта задача автоматическим образом неразрешима в принципе. А в случае реляционных баз данных она имеет еще и проблемы связанные самой RDBMS - атомом там может являтся либо строка либьо транзакция. И фактом является то что транзакционных Async MMR вообще никто не делает - это бесполезно в следствии слишко общего подхода RDBMS - в результате конфликта атом типа тразакция вообще не разрулить (сложно) - потому подход построчный - и все равно с рукопашной логикой. А решать конфликты построчно - большой геморой.

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

>Т.е. эта система не является примером распределенной иерархической базы данных.

И еще она корованы не грабит.

>. Это четыре отдельные системы, и целостность данных как-то обеспечивается только на уровне сервера, но не системы в целом.

Это сеть с сотнями нодов и линейными возможностями увеличения числа нодов двумя моделями синхрнного состояния - между парами и во всей сети и Async MMR свойствами. Данные целостны на уровне всей сети в целом.

>Единственное о чем вы не говорите - это о том, что ваша система просто не является системой управления базой данных поскольку не обеспечивает требуемых функций.

Каких функций она не обеспечивает? Все что вы перечисляли это конкретные свойства _реляционных_ систем которые в отрыве от них смысла не имеют. Конечно она не обесмечивает JOINов таблиц - потому что нет таблиц которые надо джойнить а соответствующая функция выболняется другимим методами. Кончено в ней нет M:N - потому что этим термином обозначается связь между реляционными таблицами а если их нет - M:N никакого смысла не имеет. Все остальное - транзакции, хранение, доступ, даже Async MMR система обеспечивает. При чем быстрее и удобнее чем реляционная Субд. Вы поищите для топичного мускуля решения задачи AsyncMMR. Если вообще найдете. Оракловые решения это вообще смешно - сейчаc футпринт этого решения смешной - десктопные агенты занимают 6 мегабайт в архиве - любое решение с RDBMS превратит систему из маленьлкой програмки в гигабайтного монстра который нахрен никому не нужен, за десятки тысяч долларов - эти решения относятся к энтерпрайз версиям.

Что вам еще надо от базы данных?

>Отлично :) А теперь как вы на ссылках сделаете связь много-ко-много? Оба объекта будут иметь списки ссылок на другие? Тогда есть 2 списка данных и это означает, что рано или поздно они разъедутся!

Разязочная таблица при M:N это не такие же 2 списка нет?

> Нормальные формы для того и придуманы были ;)

НУ нормальизуйте M:N до отсутствия двух списков в развязачной таблице.

>А у вас?

Точно так же.

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

Применительно к моим задачам в отрасли в которой я работаю у меня мнение что RDBMS - сливает.

>Как они это будут делать на самописной поделке - не понятно.

Очень просто - у них таких проблем не будет. Одним из свойств наших систем стало существенное упрощение администрирования и увеличение скоростей работы. Им просто не надо этим заниматься. И стоит система не у 30-40 клиентов а это сотни агентов (серверных и клиентски). у десятков клиентов.

>А ведь еще есть миграция данных. и это не самый простой зверь.

О да - это просто песня миграция данных на новые версии в реляционной базе. Это еще одна область где мы наконец-то вздохнули спокойно когда выкинули RDBMS.

>так что вместо джойнов? циклы через связанные данные?

Зачем? Джойн связывает данные. А они уже связаны.

А "циклы" - это несерьезно - хотя можно применить и их. Спецрешений в виде языков анализа деревьев как есть так и придумать можно много. Просто это не SQL.

>как разруливаются конфликты репликации?!?

Я там выше писал уже.

>http://www.opensolaris.org/os/about/sun_contributor_agreement/

ТАкой же пункт был у MySQL AB. А в мозилле например принимают только 3-licensed код а с GPL посылают куда подальше.

а еще забери эти хтмл и цсс. достали они уже