| 1.1, klalafuda (?), 00:46, 16/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Foreign keys not supported. Partitioned tables do not support foreign keys. This means that:
И это в пре-5.5! Все, закапывайте :-/
PS: Да, SIGNAL/RESIGNAL конечно полезно. Хотя что мешало сделать их N лет назад вопросы открытый. Но партиции без внешних ключей - их можно сказать что просто нет. Отсутствуют как класс. Ибо смысл.
| | |
| |
| 2.2, tty (??), 02:40, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
 сейчас Оракл всё поправит в Мускуле :) и будет MyOracle :)
| | |
| |
| 3.15, klalafuda (?), 11:33, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Скорее MyRacle. Хотя сомневаюсь я в этом :-/ Все больше смотрю в сторону pgsql. Тем более что и в среднем позитивный опыт работы с ней имеется. Хотя и там не без камней.
| | |
|
| 2.3, gogo (?), 02:46, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Батенька, а вы вообще читали о каком продукте идет речь? Это mysql, а не mssql. Он должен БЫСТРО сделать ПРОСТУЮ работу. А остальное для него - от лукавого, в угоду извращенцам программистам и конкурентам.
Для, например, банерной сети внешние индексы на фик не нужны. Нужно записал/прочитал.
| | |
| |
| 3.5, X (?), 03:56, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Он должен БЫСТРО сделать ПРОСТУЮ работу.
По-моему эта ниша занята sqlite, а в нише классом повыше PostgreSQL. :) Так что пора признать MySQL свое упустил лет 5-6 назад еще.
| | |
|
| 2.6, Kaiser (ok), 04:21, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
А вы документацию то почитайте, внешние ключи там уже много лет как есть.
| | |
| |
| 3.13, klalafuda (?), 10:39, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Но на таблицах разбитых на партиции их *нет*. Причем независимо от того, какой используется движок включая InnoDB. И судя по всему ещё оочень долго не появятся. Я такие надежды питал на 5.1 где они появились а меня так жестоко и по-иезуитски обломали. Что не может не удручать :-/
| | |
|
| 2.10, Антон (??), 09:42, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>
>> Foreign keys not supported. Partitioned tables do not support foreign keys. This means that:
>
>И это в пре-5.5! Все, закапывайте :-/
Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам. Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.
| | |
| |
| 3.16, Edgar Codd (?), 11:42, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> ... структуру с контролем целостности на уровне приложения.
Если приложений больше 1-го для доступа к данным? Будет к примеру 10 ;) (на Perl, PHP, C, Python и т. д.), во всех будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных языках?
Может быть, контроль целостности это все же удел БД, а не приложений. Как считаете?
| | |
| |
| 4.18, pro100master (ok), 14:00, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> ... структуру с контролем целостности на уровне приложения.
>
>Если приложений больше 1-го для доступа к данным? Будет к примеру 10
>;) (на Perl, PHP, C, Python и т. д.), во всех
>будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных
>языках?
>
>Может быть, контроль целостности это все же удел БД, а не приложений.
>Как считаете?
от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах?
А по поводу логики в языках, вам на каком языке написать
условие вида:
если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;
задача! афигеть, товарищ, правда :)))
| | |
| |
| 5.19, klalafuda (?), 15:15, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах?
Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов к данной таблице. При этом физически табличка может занимать буквально единицы от силы -десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по бОльшей части живет в кеше базы.
> А по поводу логики в языках, вам на каком языке написать
условие вида:
если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;
Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами?
| | |
| |
| 6.20, pro100master (ok), 17:35, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много >терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов >к данной таблице. При этом физически табличка может занимать буквально единицы от силы >-десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по >бОльшей части живет в кеше базы.
вы путаете и это пугает, что у нас такие "спецы". Партиция в этом случае вас абсолютно не спасёт. Спасёт репликация. И там хоть 1М обращений, только и знай "дочек" на чтение выстраивай в ряд.
>Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами?
это был вопрос о трудностях реализации "логики". Я не вижу труда реализовать данное условие ни на одном из языков ;)
| | |
|
| 5.21, Edgar Codd (?), 04:16, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Что там хранить, что не уместится на много-много терабайтных раидах?
Про то что не в размере и скорости носителя счастье Вам уже написали.
> А по поводу логики в языках, вам на каком языке написать
> условие вида:
> если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
> если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;
Давайте о погоде поговорим еще может быть? Какое отношение соединение приложения к разным узлам имеет к ЦЕЛОСТНОСТИ базы данных? Речь шла о том, что база данных должна сама следить за связями между таблицами, на то она и RDBMS. Не говорю уже о том, что с помошью триггеров и хранимых процедур, в нормальных RDBMS можно и реализовывать целостностиь данных между разными базами данных. И это будет в разы быстрее и надежнее по коду и затраченному времени разработки, чем реализовать проверку в приложении (клиенте) к базе данных.
| | |
| |
| 6.22, pro100master (ok), 09:50, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
> Про то что не в размере и скорости носителя счастье Вам уже написали.
> Давайте о погоде поговорим еще может быть?
давайте определимся, мы о вебе или мы о сферическом коне? Если да, то вы один на миллион. Потому что b2b, b2c приложений в вебе примерно в такой пропорции к сайтам вообще. Поэтому делайте скидку на универсальность. Если не о вебе, то, возможно вам это понравится, я считаю, что мускулу не место в "невеб" бизнес приложениях. Как и не место постгри, как бы не мечтали приверженцы последнего.
| | |
| |
| 7.23, Edgar Codd (?), 10:35, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> давайте определимся, мы о вебе или мы о сферическом коне?
В принципе, если вы не заметили о чем шла речь, то намекну Вам, что речь шла о внешних ключах для определенного типа таблиц, а не о конях и вебах... :)
Ну а что касается "коней"... Да хоть и вебе. С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД? Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры?
А может это происходит, потому что программеру пишущему эти приложения неизвестно что RDBMS, это не просто хранилище данных, а несколько больше. И на самом деле, беда кодящего бедолаги в том, что он дальше PHP ничего не хочет видеть. :)
| | |
|
|
|
|
|
|
| 1.14, klalafuda (?), 11:31, 16/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам.
Ну не обязательно именно дискам.
Старая как мир плюшка - ручное разбиение высоконагруженной таблицы ABC на N идентичных по структуре таблиц ABC00..ABCn с выборкой конкретной таблицы по какому то простому признаку скажем от primary key. Иногда это позволяет в разы а иногда и на порядки снизить общую нагрузку на базу, если ABC является бутылочным горлышком. Банально из-за снижения вероятности ожидания на блокировке.
Однако, возникает и естественное неудобство при работе с такой вот вручную разбитой 'таблицей'. Особенно, если требуется сделать какую то выборку из всей таблицы. Именно тут IMHO partitioning на уровне RDBMS был бы как нельзя кстати - и волки сыты и овцы целы. Конечно, вопрос об конечной эффективности встроенного разбиения могут показать лишь тесты и работа на реальной системе, но все предпосылки налицо.
Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен.
> Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.
'Тот объем данных' - понятие сильно растяжимое. Все может радостно встать колом практически независимо от железа даже на каких то 1M записей в несложной табличке, если к ней ведётся разношерстный параллельный доступ на чтение/модификацию.
Отказ же от внешних ключей и перенос контроля за целостностью базы на уровень приложения лишь потому, что 'почему то все тормозит' - это совершенно не аргумент при дизайне системы. Разве что камень в огород конкретной RDBMS.
| | |
| |
| 2.17, pro100master (ok), 13:52, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен.
если вам так пофиг на скорость, то проще распределенную ФС использовать, чем добавлять лишнюю сущность в уравнение вероятности сбоя.
| | |
|
| 1.25, pro100master (ok), 17:55, 17/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД?
-----
не путайте сложную структуру с логикой. Это бесово. Если вы хотите связать действительно сложную структуру, логику и, при этом, говорить о целостности всего этого, то мускулу еще лет адцать идти к этому. Это задачи оракла. Почему? Потому. Ничто, кроме как приложение работающее на самом сервере БД, не обеспечит вам достаточную целостность. Ключи это просто примитивы, типа для бедных.
Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры?
-----
удивлю, 99.9% сайтов не используют и не собираются использовать это. Ссылок не дам. Посмотрите самые тяжелые oss-проекты. Они примитивны, с точки зрения БД и кода на стороне БД.
| | |
|
