 |
|
Модераторы: LSD |
 
|
|
Надежность MySQL 
| slang |
|
|||
 Опытный  Профиль Группа: Участник Сообщений: 455 Регистрация: 7.3.2004 Репутация: нет Всего: 0 |
Какой вариант работы лучше выбрать? Чтобы операции выполнялись и контролировались средствами СУБД, которые можно выполнить и контролировать с ее помощью. Или же средствами PHP. В последнем случае, безусловно снижается быстродействие и значительно увеличивается нагрузка на сервер приложений. В первом случае повышается нагрузка на БД.
Однозначно, выход из строя СУБД - может привести к более тригическим последствиям, нежели временная недоступность скриптов. Но насколько велика вероятность значительного повышения нагрузки на СУБД в следующем случае: Существует таблица из трех столбцов: field_1, field_2, field_3. Необходимо производить контроль, чтобы сочетание field_2 и field_3 не повторялось. На уровне СУБД это можно сделать
В случае контроля на уровне PHP, необходимо постоянно контролировать записываемые данные в эту таблицу. Этот пример, конечно, не очень яркий, но вопрос возник именно на нем. -------------------- Запчасти на иномарки www.avtograd55.ru. Если есть время - зайдите и посоветуйте что исправить и что доработать. |
|||
|
||||
Загрузка ...
| Ignat |
|
|||
 Флудератор Профиль Группа: Экс. модератор Сообщений: 4030 Регистрация: 19.4.2004 Где: غيليندزيك مدينة Репутация: нет Всего: 73 |
Полный запрос приведи, пожалуйста. И не проще ли изначально выставить уникальный индекс?
-------------------- Теперь при чем :P |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Контроль средствами БД всегда надежнее контроля средствами клиента. А трагические последствия из-за "выхода из строя сервера СУБД" не зависят от того, где выполняется контроль, они зависят исключительно от грамотности организации резервногокопирования. если оно вообще есть.
ИМХО. PS. На 99% уверен, что сервер MySQL и веб-сервер физически располагаются на одной машине - если так, то вопрос (вернее ссылки на нагрузку отдельного процесса) вообще лишен смысла. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| Mal Hack |
|
|||
 Мудрый... Профиль Группа: Участник Клуба Сообщений: 9926 Регистрация: 15.2.2004 Репутация: нет Всего: 261 |
Это все пошло отсюда: http://forum.vingrad.ru/index.php?showtopic=61443&hl=
|
|||
|
||||
| LSD |
|
|||
 Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Полностью согласен. По поводу нагрузки: если для проверки на уникальность надо будет выполнять дополнительные запросы, то конечно производительность будет меньше, т.к. выполнение: SELECT с GROUP BY, создаст большую нагрузку на БД, чем проверка UNIQUE индекса. Единственный вариант, если проверка на уникальность реализуется кодом (хотя и смутно представляю как это сделать), тогда возможны варианты. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
|||
|
||||
| SergeBS |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1111 Регистрация: 10.6.2005 Где: Владимир Репутация: 1 Всего: 22 |
LSD
На клиенте это делать неправильно, поскольку клиент может стать и другим. Сделает какой-нибудь Вася Пупкин мелкую приладу для просмотра и редактирования маленького интересного ему кусочка - и привет. Тут вы с Akina правы. Специально для поддержки сложных бизнес-правил созданы триггеры и хранимые процедуры. Тут - бизнес-правило. Так зачем запросы приплетать? "Непрофильное" применение. Индексом контролировать неприятно - гарантировано притормаживание на любых операциях изменения таблицы. И неудобно. Они не для этого. Даже уникальные. |
|||
|
||||
| LSD |
|
||||
|
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
А как контролировать уникальность? Может какие БД и делают это иначе, но для Oracle верно:
-------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
||||
|
|||||
| Bikutoru |
|
|||
|
Увлекающийся Профиль Группа: Участник Сообщений: 522 Регистрация: 24.5.2005 Где: Москва Репутация: нет Всего: 22 |
Поправьте меня, если я не прав, но ни хранимых процедур, ни триггеров MySQL не имеет. Так что альтернативы только две: 1. делать SELECT перед каждым UPDATE/INSERT; 2. использовать уникальный индекс. -------------------- Человек, словно в зеркале мир — многолик, Он ничтожен — и он же безмерно велик! Омар Хайям |
|||
|
||||
| SergeBS |
|
||||||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1111 Регистрация: 10.6.2005 Где: Владимир Репутация: 1 Всего: 22 |
Bikutoru
Поправляю  MySQL 5.0.2 (дождались-таки!)
Так что способов хватает: №1,№2 - см. выше. LSD Если с нормальностью базы у тебя нормально (т.е. до 3 НФ довел), то уникальный индекс = уникальному полю.Более понятно - я излагал про уникальные индексы по _нескольким_полям_. Они неудобны. Ну вылетело исключение по неуникальности - гадай, в каком поле неверный ввод. И чеши репу насчет исправления ситуации заодно. А если индекс по одному уникальному полю - так все разруливается легко и просто. Пока правильно поле не заполнено - не выпускать из него, а в качестве угрозы "Щас всю запись коцну, если по-хорошему не понимаешь!" И производительность, и поиск - все люкс в качестве бонуса . |
||||||
|
|||||||
| LSD |
|
||||
|
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Ну тогда вопрос как реализовать такую штуку: есть список объектов, и есть список состояний для этих объектов. Объекту на определенный момент времениможно назначить, определенное действие, но только одно, или вообще ничего не назначать. С уникальностью по двум полям это делается элементарно: таблица [TIMESTAMP, OBJ_ID, ACT_ID] и ставим уникальный индекс на колонки [DATE, OBJ_ID] (а лучше первичный ключ).
В том то и дело что неверные данные во всех полях, т.к. уникальность определяется по все полям сразу. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
||||
|
|||||
| SergeBS |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1111 Регистрация: 10.6.2005 Где: Владимир Репутация: 1 Всего: 22 |
LSD
[/quote] В том то и дело что неверные данные во всех полях, т.к. уникальность определяется по все полям сразу. [quote] Не бывает. 1 решение: для каждого объекта определяешь список допустимых возможных состояний. Т.е. либо для каждого объекта - свой справочник состояний, либо для каждого состояния - куча (1..N) логических полей, определяющих, может i-й объект из всего N объектов находиться в этом состоянии или нет. Что лучше - зависит от степени перекрытия сосотояний у разных объектов. Если у объекта 2 взаимно влияющих поля действий - у действий 2-мерная матрица M*N где M - число состояний 1 поля, n - число состояний 2-го, 3 - 3-хмерная аналогично. И т.д. Это решение "в лоб". Другое решение (для хорошо алгоритмируемых условий): на ввод любого поля - триггер. В триггере урезаешь список возможного ввода для остальных полей. 3 решение: а-ля мастер/волшебник. Очередность ввода полей жестко задана. По 1-му введенному определяется набор возможных значений для 2-го, после ввода 2-го - для 3-го и т.д. 4 решение: с реляционной СУБД - на иерархическую/древовидную - по сути тот же мастер ввода, где структура связей узел-листья задает возможный выбор. |
|||
|
||||
| LSD |
|
||||||||
|
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Не понял, не бывает чего?
Ага, только для той задачи, что я написал допустимые значения второго поля, можно определить только сделав select из таблицы.
Что такое триггер на поле?
То же что и пункт один, откуда брать значения для мастера/волшебника и на основе чего строить дерево? И вообще это больше касается интерфейса, а речь шла о целостности базы, ведь данные в базу может заносить и "аппаратура". Например еще одна задачка, есть таблица в которой хранятся табличные значения некой функции (пусть она будет от 3-х аргументов), соответсвенно для каждой тройки [X,Y,Z] должно быть только одно значение. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
||||||||
|
|||||||||
| SergeBS |
|
||||||||||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1111 Регистрация: 10.6.2005 Где: Владимир Репутация: 1 Всего: 22 |
LSD
Не бывает по определению. Любая запись по определению уникальна, если взять все поля. Формулирую определение по-другому: в БД отсутствуют одинаковые записи.
не триггер на поле (нет таких). При вводе любого из критичных полей - сразу попытка обновить - триггер на обновление.
Вот и впихни в триггер этот селект. Я что, твою задачу лучше тебя знаю? Ты ее вообще не изложил.
А откуда ты берешь ограничения целостности? С потолка? Тогда и здесь с потолка. И это не столько интерфейс, сколько способ _последовательного_ввода_ с проверкой на каждом этапе. Интерфейс определяется задачей.
А подумать самому? Тебе еще раз повторить? Ну на: Другое решение (для хорошо алгоритмируемых условий): на ввод любого поля - попытка update - триггер. В триггере урезаешь список возможного ввода для остальных полей. Чем урезать, объяснять? Без проблем: см. выше насчет потолка и селекта .Если способен получить только триаду значений сразу - тогда просто откат с воплем: "юзер, не пихай лажу!". Все равно другого ничего не сможешь. |
||||||||||
|
|||||||||||
| LSD |
|
||||||||
|
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
1. Это откуда такое определение интерестно? И вообще что ты понимаешь под уникальностью, различимость записей для СУБД или различимость для клиента? 2. Я говорил про все поля входящие в уникальный индекс.
А с insert что делать? И вообще, ты представляешь как увеличится нагрузка на базу, если запись обновлять не целиком а по одному полю (при условии что полей много). Плюс не все библиотеки компонентов такой изврат поддерживают (тот же DataExpress, записи вставляет/обновляет только целиком). И плюс, триггера не видят изменений сделанных другими транзакциями, так что есть шанс получить нарушение уникальности несмотря на все проверки в триггере.
Ты просто не удосужился прочитать.
А свою задачу я и без тебя решу, не переживай -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
||||||||
|
|||||||||
| SergeBS |
|
||||||||||||||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1111 Регистрация: 10.6.2005 Где: Владимир Репутация: 1 Всего: 22 |
LSD
Экий ты нудный.
Например:
Риордан не цитирую. Дейта тоже. "Проще надо быть, проще" .
А еще delete бывает. Излагалась идея - как можно сделать. На insert тоже триггер можно навесить, тот же самый. Добавлю оттуда же (см.выше):
В переводе на практику: если у тебя много полей зависит друг от друга - значит БД не нормализована. Нормализуй. В результате может, конечно получиться что-то типа - из 1 таблицы с N полями получаем N/2 таблиц с 2-мя полями в каждой, но тогда задача - не для реляционной базы, а для иерархической. Типа деревце вверх ногами . С веточками и листиками.
Если сумеешь сделать так, чтобы триггер таблицы в одной транзакции работал, а другую игнорировал, это будет НЕЧТО! Триггер на таблице висит. Срабатывает от события таблицы, неважно кто это событие вызвал.
Можешь ткнуть пальцем в _определение_уникальности ? Не в то, что ты потребовал уникального сочетания 2-х полей, а в то, которое нужно получить? Ладно. Проехали. Поскольку
|
||||||||||||||
|
|||||||||||||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0660 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |