forum.opennet.ru - "Представлена тестовая версия MySQL 5.5" (22)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Представлена тестовая версия MySQL 5.5"

Форумы Разговоры, обсуждение новостей (Public)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Представлена тестовая версия MySQL 5.5"		+/–
Сообщение от opennews on 16-Дек-09, 00:46
Представлен (http://blogs.mysql.com/kaj/2009/12/15/mysql-550-m2-a-milesto.../) тестовый выпуск MySQL 5.5.0-M2 (http://dev.mysql.com/doc/refman/5.5/en/news-5-5-0.html), созданный на основе новой экспериментальной ветки MySQL. Первый доступный для промышленной эксплуатации релиз MySQL 5.5 планируется выпустить в середине 2010 года. Версия MySQL 5.5 является первой, развиваемой в рамках новой модели (http://forge.mysql.com/wiki/Development_Cycle) подготовки релизов. Вместо нескольких экспериментальных веток (5.4, 6.0, 6.1), новые возможности теперь будут разрабатываться в единой экспериментальной ветке, без разделения на альфа и бета версии. В соответствии с новой схемой, на базе единой тестовой ветки раз в 3-6 месяцев будут выпускаться промежуточные версии с качеством кандидата в релизы (RC), в промежутке между которыми будут доступны milestone-сборки. Новые возможности будут интегрироваться в дерево исходных текстов в течение двух недель после выхода RC-сборки, ветк... URL: http://blogs.mysql.com/kaj/2009/12/15/mysql-550-m2-a-milesto.../ Новость: https://www.opennet.ru/opennews/art.shtml?num=24684
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Представлена тестовая версия MySQL 5.5, klalafuda, 00:46 , 16-Дек-09, (1) +1

Представлена тестовая версия MySQL 5.5, tty, 02:40 , 16-Дек-09, (2)

Представлена тестовая версия MySQL 5.5, Sw00p aka Jerom, 10:25 , 16-Дек-09, (12)
Представлена тестовая версия MySQL 5.5, klalafuda, 11:33 , 16-Дек-09, (15)

Представлена тестовая версия MySQL 5.5, gogo, 02:46 , 16-Дек-09, (3)

Представлена тестовая версия MySQL 5.5, X, 03:56 , 16-Дек-09, (5)

Представлена тестовая версия MySQL 5.5, Kaiser, 04:22 , 16-Дек-09, (7)

Представлена тестовая версия MySQL 5.5, X, 04:50 , 16-Дек-09, (8)

Представлена тестовая версия MySQL 5.5, Kaiser, 04:21 , 16-Дек-09, (6)

Представлена тестовая версия MySQL 5.5, vadiml, 09:45 , 16-Дек-09, (11)
Представлена тестовая версия MySQL 5.5, klalafuda, 10:39 , 16-Дек-09, (13)

Представлена тестовая версия MySQL 5.5, Антон, 09:42 , 16-Дек-09, (10)

Представлена тестовая версия MySQL 5.5, Edgar Codd, 11:42 , 16-Дек-09, (16)

Представлена тестовая версия MySQL 5.5, pro100master, 14:00 , 16-Дек-09, (18)

Представлена тестовая версия MySQL 5.5, klalafuda, 15:15 , 16-Дек-09, (19)

Представлена тестовая версия MySQL 5.5, pro100master, 17:35 , 16-Дек-09, (20)

Представлена тестовая версия MySQL 5.5, Edgar Codd, 04:16 , 17-Дек-09, (21)

Представлена тестовая версия MySQL 5.5, pro100master, 09:50 , 17-Дек-09, (22)

Представлена тестовая версия MySQL 5.5, Edgar Codd, 10:35 , 17-Дек-09, (23)

Представлена тестовая версия MySQL 5.5, klalafuda, 11:31 , 16-Дек-09, (14) +1

Представлена тестовая версия MySQL 5.5, pro100master, 13:52 , 16-Дек-09, (17)

Представлена тестовая версия MySQL 5.5, pro100master, 17:55 , 17-Дек-09, (25)

Сообщения по теме [Сортировка по времени | RSS]

1. "Представлена тестовая версия MySQL 5.5" +1 +/–

Сообщение от klalafuda on 16-Дек-09, 00:46

> Foreign keys not supported.   Partitioned tables do not support foreign keys. This means that:
И это в пре-5.5! Все, закапывайте :-/
PS: Да, SIGNAL/RESIGNAL конечно полезно. Хотя что мешало сделать их N лет назад вопросы открытый. Но партиции без внешних ключей - их можно сказать что просто нет. Отсутствуют как класс. Ибо смысл.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от tty (??) on 16-Дек-09, 02:40

сейчас Оракл всё поправит в Мускуле :) и будет MyOracle :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от Sw00p aka Jerom on 16-Дек-09, 10:25

лучше MOSql

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от klalafuda on 16-Дек-09, 11:33

Скорее MyRacle. Хотя сомневаюсь я в этом :-/ Все больше смотрю в сторону pgsql. Тем более что и в среднем позитивный опыт работы с ней имеется. Хотя и там не без камней.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от gogo on 16-Дек-09, 02:46

Батенька, а вы вообще читали о каком продукте идет речь? Это mysql, а не mssql. Он должен БЫСТРО сделать ПРОСТУЮ работу. А остальное для него - от лукавого, в угоду извращенцам программистам и конкурентам.
Для, например, банерной сети внешние индексы на фик не нужны. Нужно записал/прочитал.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от X on 16-Дек-09, 03:56

> Он должен БЫСТРО сделать ПРОСТУЮ работу.
По-моему эта ниша занята sqlite, а в нише классом повыше PostgreSQL. :) Так что пора признать MySQL свое упустил лет 5-6 назад еще.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от Kaiser (ok) on 16-Дек-09, 04:22

В PostgreSQL есть партицирование?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от X on 16-Дек-09, 04:50

>  В PostgreSQL есть партицирование?
Из каробки с версии 8.1 еще http://www.postgresql.org/docs/8.1/interactive/ddl-partition...
http://www.postgresql.org/docs/8.4/interactive/ddl-partition...
А в MySQL уже есть стабильная версия релиза где не надо быть суперпользователем чтобы создать триггер? Или может быть в MySQL есть партицирование в стабильных релизах? На сколько помню стабильным считалась ветка 5.0.x и партицирования и триггеров для несупервользователей там не было.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от Kaiser (ok) on 16-Дек-09, 04:21

А вы документацию то почитайте, внешние ключи там уже много лет как есть.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от vadiml on 16-Дек-09, 09:45

Для InnoDB

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от klalafuda on 16-Дек-09, 10:39

Но на таблицах разбитых на партиции их *нет*. Причем независимо от того, какой используется движок включая InnoDB. И судя по всему ещё оочень долго не появятся. Я такие надежды питал на 5.1 где они появились а меня так жестоко и по-иезуитски обломали. Что не может не удручать :-/

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от Антон (??) on 16-Дек-09, 09:42

>
>> Foreign keys not supported.   Partitioned tables do not support foreign keys. This means that:
>
>И это в пре-5.5! Все, закапывайте :-/
Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам. Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от Edgar Codd on 16-Дек-09, 11:42

> ... структуру с контролем целостности на уровне приложения.
Если приложений больше 1-го для доступа к данным? Будет к примеру 10 ;) (на Perl, PHP, C, Python и т. д.), во всех будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных языках?
Может быть, контроль целостности это все же удел БД, а не приложений. Как считаете?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от pro100master (ok) on 16-Дек-09, 14:00

>> ... структуру с контролем целостности на уровне приложения.
>
>Если приложений больше 1-го для доступа к данным? Будет к примеру 10
>;) (на Perl, PHP, C, Python и т. д.), во всех
>будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных
>языках?
>
>Может быть, контроль целостности это все же удел БД, а не приложений.
>Как считаете?
от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах?
А по поводу логики в языках, вам на каком языке написать
условие вида:
если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;
задача! афигеть, товарищ, правда :)))

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от klalafuda on 16-Дек-09, 15:15

> от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах?
Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов к данной таблице. При этом физически табличка может занимать буквально единицы от силы -десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по бОльшей части живет в кеше базы.
> А по поводу логики в языках, вам на каком языке написать
условие вида:
если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;
Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от pro100master (ok) on 16-Дек-09, 17:35

>Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много >терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов >к данной таблице. При этом физически табличка может занимать буквально единицы от силы >-десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по >бОльшей части живет в кеше базы.
вы путаете и это пугает, что у нас такие "спецы". Партиция в этом случае вас абсолютно не спасёт. Спасёт репликация. И там хоть 1М обращений, только и знай "дочек" на чтение выстраивай в ряд.
>Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами?
это был вопрос о трудностях реализации "логики". Я не вижу труда реализовать данное условие ни на одном из языков ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от Edgar Codd on 17-Дек-09, 04:16

> Что там хранить, что не уместится на много-много терабайтных раидах?
Про то что не в размере и скорости носителя счастье Вам уже написали.
> А по поводу логики в языках, вам на каком языке написать
> условие вида:
> если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
> если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;
Давайте о погоде поговорим еще может быть? Какое отношение соединение приложения к разным узлам имеет к ЦЕЛОСТНОСТИ базы данных? Речь шла о том, что база данных должна сама следить за связями между таблицами, на то она и RDBMS. Не говорю уже о том, что с помошью триггеров  и хранимых процедур, в нормальных RDBMS можно и реализовывать целостностиь данных между разными базами данных. И это будет в разы быстрее и надежнее по коду и затраченному времени разработки, чем реализовать проверку в приложении (клиенте) к базе данных.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от pro100master (ok) on 17-Дек-09, 09:50

> Про то что не в размере и скорости носителя счастье Вам уже написали.
> Давайте о погоде поговорим еще может быть?
давайте определимся, мы о вебе или мы о сферическом коне? Если да, то вы один на миллион. Потому что b2b, b2c приложений в вебе примерно в такой пропорции к сайтам вообще. Поэтому делайте скидку на универсальность. Если не о вебе, то, возможно вам это понравится, я считаю, что мускулу не место в "невеб" бизнес приложениях. Как и не место постгри, как бы не мечтали приверженцы последнего.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от Edgar Codd on 17-Дек-09, 10:35

> давайте определимся, мы о вебе или мы о сферическом коне?
В принципе, если вы не заметили о чем шла речь, то намекну Вам, что речь шла о внешних ключах для определенного типа таблиц, а не о конях и вебах... :)
Ну а что касается "коней"... Да хоть и вебе. С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД? Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры?
А может это происходит, потому что программеру пишущему эти приложения неизвестно что RDBMS, это не просто хранилище данных, а несколько больше. И на самом деле, беда кодящего бедолаги в том, что он дальше PHP ничего не хочет видеть. :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Представлена тестовая версия MySQL 5.5" +1 +/–

Сообщение от klalafuda on 16-Дек-09, 11:31

> Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам.
Ну не обязательно именно дискам.
Старая как мир плюшка - ручное разбиение высоконагруженной таблицы ABC на N идентичных по структуре таблиц ABC00..ABCn с выборкой конкретной таблицы по какому то простому признаку скажем от primary key. Иногда это позволяет в разы а иногда и на порядки снизить общую нагрузку на базу, если ABC является бутылочным горлышком. Банально из-за снижения вероятности ожидания на блокировке.
Однако, возникает и естественное неудобство при работе с такой вот вручную разбитой 'таблицей'. Особенно, если требуется сделать какую то выборку из всей таблицы. Именно тут IMHO partitioning на уровне RDBMS был бы как нельзя кстати - и волки сыты и овцы целы. Конечно, вопрос об конечной эффективности встроенного разбиения могут показать лишь тесты и работа на реальной системе, но все предпосылки налицо.
Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен.
> Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.
'Тот объем данных' - понятие сильно растяжимое. Все может радостно встать колом практически независимо от железа даже на каких то 1M записей в несложной табличке, если к ней ведётся разношерстный параллельный доступ на чтение/модификацию.
Отказ же от внешних ключей и перенос контроля за целостностью базы на уровень приложения лишь потому, что 'почему то все тормозит' - это совершенно не аргумент при дизайне системы. Разве что камень в огород конкретной RDBMS.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от pro100master (ok) on 16-Дек-09, 13:52

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "Представлена тестовая версия MySQL 5.5" +/–

Сообщение от pro100master (ok) on 17-Дек-09, 17:55

С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД?
-----
не путайте сложную структуру с логикой. Это бесово. Если вы хотите связать действительно сложную структуру, логику и, при этом, говорить о целостности всего этого, то мускулу еще лет адцать идти к этому. Это задачи оракла. Почему? Потому. Ничто, кроме как приложение работающее на самом сервере БД, не обеспечит вам достаточную целостность. Ключи это просто примитивы, типа для бедных.
Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры?
-----
удивлю, 99.9% сайтов не используют и не собираются использовать это. Ссылок не дам. Посмотрите самые тяжелые oss-проекты. Они примитивны, с точки зрения БД и кода на стороне БД.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Представлена тестовая версия MySQL 5.5"		+1 +/–
Сообщение от klalafuda on 16-Дек-09, 00:46
> Foreign keys not supported. Partitioned tables do not support foreign keys. This means that: И это в пре-5.5! Все, закапывайте :-/ PS: Да, SIGNAL/RESIGNAL конечно полезно. Хотя что мешало сделать их N лет назад вопросы открытый. Но партиции без внешних ключей - их можно сказать что просто нет. Отсутствуют как класс. Ибо смысл.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от tty (??) on 16-Дек-09, 02:40
	сейчас Оракл всё поправит в Мускуле :) и будет MyOracle :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от Sw00p aka Jerom on 16-Дек-09, 10:25
	лучше MOSql
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от klalafuda on 16-Дек-09, 11:33
	Скорее MyRacle. Хотя сомневаюсь я в этом :-/ Все больше смотрю в сторону pgsql. Тем более что и в среднем позитивный опыт работы с ней имеется. Хотя и там не без камней.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от gogo on 16-Дек-09, 02:46
	Батенька, а вы вообще читали о каком продукте идет речь? Это mysql, а не mssql. Он должен БЫСТРО сделать ПРОСТУЮ работу. А остальное для него - от лукавого, в угоду извращенцам программистам и конкурентам. Для, например, банерной сети внешние индексы на фик не нужны. Нужно записал/прочитал.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от X on 16-Дек-09, 03:56
	> Он должен БЫСТРО сделать ПРОСТУЮ работу. По-моему эта ниша занята sqlite, а в нише классом повыше PostgreSQL. :) Так что пора признать MySQL свое упустил лет 5-6 назад еще.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от Kaiser (ok) on 16-Дек-09, 04:22
	В PostgreSQL есть партицирование?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от X on 16-Дек-09, 04:50
	> В PostgreSQL есть партицирование? Из каробки с версии 8.1 еще http://www.postgresql.org/docs/8.1/interactive/ddl-partition... http://www.postgresql.org/docs/8.4/interactive/ddl-partition... А в MySQL уже есть стабильная версия релиза где не надо быть суперпользователем чтобы создать триггер? Или может быть в MySQL есть партицирование в стабильных релизах? На сколько помню стабильным считалась ветка 5.0.x и партицирования и триггеров для несупервользователей там не было.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от Kaiser (ok) on 16-Дек-09, 04:21
	А вы документацию то почитайте, внешние ключи там уже много лет как есть.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от vadiml on 16-Дек-09, 09:45
	Для InnoDB
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от klalafuda on 16-Дек-09, 10:39
	Но на таблицах разбитых на партиции их нет. Причем независимо от того, какой используется движок включая InnoDB. И судя по всему ещё оочень долго не появятся. Я такие надежды питал на 5.1 где они появились а меня так жестоко и по-иезуитски обломали. Что не может не удручать :-/
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от Антон (??) on 16-Дек-09, 09:42
	> >> Foreign keys not supported. Partitioned tables do not support foreign keys. This means that: > >И это в пре-5.5! Все, закапывайте :-/ Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам. Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от Edgar Codd on 16-Дек-09, 11:42
	> ... структуру с контролем целостности на уровне приложения. Если приложений больше 1-го для доступа к данным? Будет к примеру 10 ;) (на Perl, PHP, C, Python и т. д.), во всех будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных языках? Может быть, контроль целостности это все же удел БД, а не приложений. Как считаете?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от pro100master (ok) on 16-Дек-09, 14:00
	>> ... структуру с контролем целостности на уровне приложения. > >Если приложений больше 1-го для доступа к данным? Будет к примеру 10 >;) (на Perl, PHP, C, Python и т. д.), во всех >будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных >языках? > >Может быть, контроль целостности это все же удел БД, а не приложений. >Как считаете? от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах? А по поводу логики в языках, вам на каком языке написать условие вида: если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250; если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250; задача! афигеть, товарищ, правда :)))
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	19. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от klalafuda on 16-Дек-09, 15:15
	> от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах? Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов к данной таблице. При этом физически табличка может занимать буквально единицы от силы -десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по бОльшей части живет в кеше базы. > А по поводу логики в языках, вам на каком языке написать условие вида: если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250; если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250; Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами?
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от pro100master (ok) on 16-Дек-09, 17:35
	>Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много >терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов >к данной таблице. При этом физически табличка может занимать буквально единицы от силы >-десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по >бОльшей части живет в кеше базы. вы путаете и это пугает, что у нас такие "спецы". Партиция в этом случае вас абсолютно не спасёт. Спасёт репликация. И там хоть 1М обращений, только и знай "дочек" на чтение выстраивай в ряд. >Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами? это был вопрос о трудностях реализации "логики". Я не вижу труда реализовать данное условие ни на одном из языков ;)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от Edgar Codd on 17-Дек-09, 04:16
	> Что там хранить, что не уместится на много-много терабайтных раидах? Про то что не в размере и скорости носителя счастье Вам уже написали. > А по поводу логики в языках, вам на каком языке написать > условие вида: > если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250; > если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250; Давайте о погоде поговорим еще может быть? Какое отношение соединение приложения к разным узлам имеет к ЦЕЛОСТНОСТИ базы данных? Речь шла о том, что база данных должна сама следить за связями между таблицами, на то она и RDBMS. Не говорю уже о том, что с помошью триггеров и хранимых процедур, в нормальных RDBMS можно и реализовывать целостностиь данных между разными базами данных. И это будет в разы быстрее и надежнее по коду и затраченному времени разработки, чем реализовать проверку в приложении (клиенте) к базе данных.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от pro100master (ok) on 17-Дек-09, 09:50
	> Про то что не в размере и скорости носителя счастье Вам уже написали. > Давайте о погоде поговорим еще может быть? давайте определимся, мы о вебе или мы о сферическом коне? Если да, то вы один на миллион. Потому что b2b, b2c приложений в вебе примерно в такой пропорции к сайтам вообще. Поэтому делайте скидку на универсальность. Если не о вебе, то, возможно вам это понравится, я считаю, что мускулу не место в "невеб" бизнес приложениях. Как и не место постгри, как бы не мечтали приверженцы последнего.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от Edgar Codd on 17-Дек-09, 10:35
	> давайте определимся, мы о вебе или мы о сферическом коне? В принципе, если вы не заметили о чем шла речь, то намекну Вам, что речь шла о внешних ключах для определенного типа таблиц, а не о конях и вебах... :) Ну а что касается "коней"... Да хоть и вебе. С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД? Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры? А может это происходит, потому что программеру пишущему эти приложения неизвестно что RDBMS, это не просто хранилище данных, а несколько больше. И на самом деле, беда кодящего бедолаги в том, что он дальше PHP ничего не хочет видеть. :)
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

14. "Представлена тестовая версия MySQL 5.5"		+1 +/–
Сообщение от klalafuda on 16-Дек-09, 11:31
> Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам. Ну не обязательно именно дискам. Старая как мир плюшка - ручное разбиение высоконагруженной таблицы ABC на N идентичных по структуре таблиц ABC00..ABCn с выборкой конкретной таблицы по какому то простому признаку скажем от primary key. Иногда это позволяет в разы а иногда и на порядки снизить общую нагрузку на базу, если ABC является бутылочным горлышком. Банально из-за снижения вероятности ожидания на блокировке. Однако, возникает и естественное неудобство при работе с такой вот вручную разбитой 'таблицей'. Особенно, если требуется сделать какую то выборку из всей таблицы. Именно тут IMHO partitioning на уровне RDBMS был бы как нельзя кстати - и волки сыты и овцы целы. Конечно, вопрос об конечной эффективности встроенного разбиения могут показать лишь тесты и работа на реальной системе, но все предпосылки налицо. Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен. > Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения. 'Тот объем данных' - понятие сильно растяжимое. Все может радостно встать колом практически независимо от железа даже на каких то 1M записей в несложной табличке, если к ней ведётся разношерстный параллельный доступ на чтение/модификацию. Отказ же от внешних ключей и перенос контроля за целостностью базы на уровень приложения лишь потому, что 'почему то все тормозит' - это совершенно не аргумент при дизайне системы. Разве что камень в огород конкретной RDBMS.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Представлена тестовая версия MySQL 5.5"		+/–
	Сообщение от pro100master (ok) on 16-Дек-09, 13:52
	> Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен. если вам так пофиг на скорость, то проще распределенную ФС использовать, чем добавлять лишнюю сущность в уравнение вероятности сбоя.
	Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору

25. "Представлена тестовая версия MySQL 5.5"		+/–
Сообщение от pro100master (ok) on 17-Дек-09, 17:55
С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД? ----- не путайте сложную структуру с логикой. Это бесово. Если вы хотите связать действительно сложную структуру, логику и, при этом, говорить о целостности всего этого, то мускулу еще лет адцать идти к этому. Это задачи оракла. Почему? Потому. Ничто, кроме как приложение работающее на самом сервере БД, не обеспечит вам достаточную целостность. Ключи это просто примитивы, типа для бедных. Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры? ----- удивлю, 99.9% сайтов не используют и не собираются использовать это. Ссылок не дам. Посмотрите самые тяжелые oss-проекты. Они примитивны, с точки зрения БД и кода на стороне БД.
Высказать мнение \| Ответить \| Правка \| Наверх \| Cообщить модератору