The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Oracle или MySQL?"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Программирование под UNIX (Public)
Изначальное сообщение [Проследить за развитием треда]

"Oracle или MySQL?" 
Сообщение от Serezha Искать по авторуВ закладки(??) on 05-Дек-04, 12:32  (MSK)
Чем отличаются?
Возникла необходимость собирать данные в таблицу с целью их дальнейших разноконтекстных обработок и представлений. Хочется выбрать рпавильный сервер. Как я понял (может быть неправильно), наиболее мощной системой является Oracle, однако во многих дистрибутивах Linux (в частности в моем RH9) поставляется MySQL. Хотелось бы получить пояснения насчет преимуществ и недостатков MySQL и Oracle по сравнению друг с другом. Где почитать?
  Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

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

1. "Oracle или MySQL?" 
Сообщение от DeadMustdie emailИскать по авторуВ закладки(??) on 05-Дек-04, 15:33  (MSK)
Хм, ну и вопросик... Из разряда:
  Что лучше: Мерседес E-класса или ВАЗ-2107?

Ответ: смотря по потребностям и финансовым возможностям.

MySQL получил большое распространение, ибо если созданные
на основе данной СУБД приложения не распространяешь либо
распространяешь под GPL, то - халява. Технологически MySQL
есть штука весьма мощная, и его возможностей большинству
хватает.

Однако если объём хранилища и степень его связности велики,
штанишки MySQL оказываются коротковаты. Ни эффективная работа
при сверхвысокой интенсивности транзакций над общими таблицами,
ни способность эффективно утилизировать возможности "big iron"
для выполнения поступающих запросов не являются сильными сторонами
данной СУБД. А data warehouse на MySQL строить, IMHO, безумие.
Однако доля приложений, которым это всё надо, совсем невелика.
И для них существуют такие монстры, как DB2 и Oracle; до недавнего
времени - Informix. Может быть, ещё Teradata. Стоимость лицензии
на ORACLE начинается с USD 1000.

Резюме: для "собирания данных в таблицу с целью их дальнейших
разноконтекстных обработок и представлений" с ушами хватит
MySQL. Или, скажем, PostgreSQL. ВАЗ, он тоже неплохо ездит.
Меньше бензина жрёт и в обслуживании намного дешевле.

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

2. "Oracle или MySQL?" 
Сообщение от dimus Искать по авторуВ закладки(??) on 06-Дек-04, 15:24  (MSK)
PostgreSQL рулит. Он мощнее MySQL, распространяется под нормальной лицензией. Недавно я слил себе новую версию. Установка заняла минут 30 -  40, из которых большая часть пошла на настройку - надо завести пользователя postgres, инициализировать БД и добавить в стартовые скрипты запуск сервера. На сайте есть хорошая книга, правда на английском, где подробно все это описано. Попробуй - думаю что не пожалеешь.
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "Oracle или MySQL?" 
Сообщение от Serezha Искать по авторуВ закладки(??) on 06-Дек-04, 22:39  (MSK)
>Хм, ну и вопросик... Из разряда:
>  Что лучше: Мерседес E-класса или ВАЗ-2107?

Извините, если я вас удивил, просто базами данных я ранее не пользовался. Весь мой опыт хранения данных - обычные текстовые таблички, где колонки разделяются, например, симолом '\t'.

>Ответ: смотря по потребностям и
> финансовым возможностям.

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

>Однако если объём хранилища и степень его связности велики,
>штанишки MySQL оказываются коротковаты. Ни эффективная работа

Объем может превышать 1e5 записей, причем, видимо, они будут помещаться в нескольких таблицах, связанных ключами.

>ни способность эффективно утилизировать возможности "big iron"

А какие это возможности?

>данной СУБД. А data warehouse на MySQL строить, IMHO, безумие.

warehous - это что-то типа стандартного комплекса взаимосвязанных баз данных для огромных финансовых корпораций?

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

>И для них существуют такие монстры, как DB2 и Oracle; до недавнего

А в чем монстризм? Больше места на диске, более изящный и правильный код, меньше ошибок, больше настроек?

>Стоимость лицензии
>на ORACLE начинается с USD 1000.

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

>
>Резюме: для "собирания данных в таблицу с целью их дальнейших
>разноконтекстных обработок и представлений" с ушами хватит
>MySQL. Или, скажем, PostgreSQL. ВАЗ, он тоже неплохо ездит.
>Меньше бензина жрёт и в обслуживании намного дешевле.

А обслуживание Oracle более накладно?

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

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

4. "Oracle или MySQL?" 
Сообщение от DeadMustdie emailИскать по авторуВ закладки(??) on 07-Дек-04, 21:47  (MSK)
>>Однако если объём хранилища и степень его связности велики,
>>штанишки MySQL оказываются коротковаты. Ни эффективная работа
>
>Объем может превышать 1e5 записей, причем, видимо, они будут
>помещаться в нескольких таблицах, связанных ключами.
>

Это совсем немного.

>>ни способность эффективно утилизировать возможности "big iron"
>
>А какие это возможности?
>

Главным образом, гигантская память с неоднородным временем доступа,
хитроумная высокопараллельная подсистема ввода-вывода, а также
большое количество процессоров. На уровне ОС многое делается
для обеспечения эффективной утилизации всего этого богатства,
однако и от СУБД очень многое зависит. Впрочем, если судить по
Вашему описанию задачи, в данном конкретном случае для Вас всё
это несущественно. Если бы предполагаемый объём операций над
хранилищем составлял, скажем, с четверть миллиона ежедневных
вставок либо обновлений ежедневно, тогда имело бы смысл огород
разводить.

>>данной СУБД. А data warehouse на MySQL строить, IMHO, безумие.
>
>warehous - это что-то типа стандартного комплекса
>взаимосвязанных баз данных для огромных
>финансовых корпораций?
>

Я не распологаю моральными силами и временем для сколько-нибудь
полного ответа. Можно посмотреть
http://en.wikipedia.org/wiki/Data_warehouse.

Существуют стандартные решения для организации корпоративного
хранилища информации. Сам термин существенно шире.

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

Как обычно - смотря на какой базе и при каком (качественно и
количественно) потоке запросов. На MySQL живёт LiveJournal,
нагрузочка на БД у них - не дай боже такое самому увидеть.
Справляются за счёт грамотного распределения данных по множеству
баз на разных серверах.

>>И для них существуют такие монстры, как DB2 и Oracle; до недавнего
>
>А в чем монстризм? Больше места на диске, более изящный и правильный
>код, меньше ошибок, больше настроек?
>

Насчёт "больше места на диске" - размер дистрибутива малосущественен
(кроме разве что совсем маленьких БД), а размеры хранимых сырых данных
для хранилищ сравнимого размера обычно более-менее одинаков, даже
для разных СУБД. Разброс в 10-20% IMHO не существенен.

Насчёт "меньше ошибок" - может, и так. Баги есть у всех; здесь трудно
сравнивать.

Говоря про "монстризм" (кстати, смачное слово:), я имел в виду то,
что промышленные СУБД весьма хорошо масштабируются "вверх" (больший
объём хранимых данных, больше запросов, плюс более злое железо -
и работа снова пошла, программных затыков нет), но у них есть
явная планка, "ниже" которой они масштабироваться не могут (объём
усилий по настройке и мощность железа не могут быть ниже X и Y,
соответственно). Так вот эта нижняя планка реально задрана весьма
высоко. Можно и не допрыгнуть.

>>Стоимость лицензии
>>на ORACLE начинается с USD 1000.
>
>А у них в лицензии написано, кажется, что я могу бесплатно использовать
>Oracle для разработки. Стало быть, если я свои разработки не
>распространяю, а уж тем более не продаю, то вроде ничего не нарушается.
>Так ли это?
>

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

>
>А обслуживание Oracle более накладно?
>

Пожалуй, да. По крайней мере, специалиста-администратора найти труднее,
и денег он запросит явно больше.

>А если база впоследствии разрастется/усложнится до таких параметров,
>что понадобится Oracle, легко ли потом будет данные из формата одной
>базы перегнать в формат другой?

Смотря насколько сложна структура базы данных, используются ли
специфические мозможности (типа полей автоинкремента, которых
в ORACLE в явном виде не водится). СУБД сродни игле - если
крепко сел, соскочить тяжело.

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

5. "Oracle или MySQL?" 
Сообщение от ACCA Искать по авторуВ закладки(ok) on 18-Фев-05, 23:59  (MSK)
>Объем может превышать 1e5 записей, причем, видимо, они будут помещаться в нескольких
>таблицах, связанных ключами.

1e5 записей - это фигня для любого SQL (MS SQL не считается).
IMHO ты заметишь разницу между Oracle и MySQL при объёме порядка 1e12 записей, причём на базах без особых наворотов MySQL будет заметно быстрее.

Oracle позволяет делать мощную обработку внутри самого сервера, он таскает свои HTTP, XML и Java. Однако если у тебя многоуровневая архитектура со своим сервером приложений, то это становится не фичей, а багом - куча ресурсов пожирается впустую.

Ещё MySQL по умолчанию отдаётся через Unix socket, который не виден из сети, а Oracle отдаёт минимум три порта через TCP.

Я сейчас перебираюсь с MySQL на Oracle, время от времени матерно ругаюсь. Например в Oracle нет способа отдать права на базу, нужно тупо перечислять каждую таблицу, view, функцию и проч.

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

6. "Oracle или MySQL?" 
Сообщение от dimus Искать по авторуВ закладки(??) on 21-Фев-05, 09:19  (MSK)
А почему не на Postgre?
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "Oracle или MySQL?" 
Сообщение от Dead Mustdie emailИскать по авторуВ закладки on 21-Фев-05, 12:13  (MSK)
>1e5 записей - это фигня для любого SQL (MS SQL не считается).

Последний MSSQL - весьма нехилая штука. Собственно,
единственый серьёзный его недостаток - это то, что он "MS"
и иные платформы не поддерживает.

Не путайте тёплое с мягким, а MSSQL с MS Access ;-)

>причём на базах без особых наворотов MySQL будет заметно
>быстрее.

Совсем не факт. При грамотной настройке за ORACLE трудно угнаться.
Да и ресурсы больших тачек оно лучше утилизирует.

>
>Oracle позволяет делать мощную обработку внутри самого сервера,
>он таскает свои HTTP, XML и Java. Однако если у тебя
>многоуровневая архитектура со своим сервером приложений,
>то это становится не фичей, а багом - куча ресурсов
>пожирается впустую.
>

ORACLE в этом смысле вполне гибкая штука.
Если какая фича не требуется, то её можно либо вовсе не ставить,
либо попросту не запускать.

>Ещё MySQL по умолчанию отдаётся через Unix socket, который не виден из
>сети, а Oracle отдаёт минимум три порта через TCP.

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

>Я сейчас перебираюсь с MySQL на Oracle, время от времени матерно ругаюсь.
>Например в Oracle нет способа отдать права на базу, нужно тупо
>перечислять каждую таблицу, view, функцию и проч.

Где-то я PL/SQL-ный скрыпт видел для цели.
Собственно, дело-то плёвое: выбираешь объекты из
user_tables, user_views, ..., а затем на каждый - нужный GRANT.
На bash + sqlplus пишется за час.

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

8. "Oracle или MySQL?" 
Сообщение от ACCA Искать по авторуВ закладки(ok) on 24-Фев-05, 19:20  (MSK)
>>Например в Oracle нет способа отдать права на базу, нужно тупо
>>перечислять каждую таблицу, view, функцию и проч.
>
>Где-то я PL/SQL-ный скрыпт видел для цели.
>Собственно, дело-то плёвое: выбираешь объекты из
>user_tables, user_views, ..., а затем на каждый - нужный GRANT.

all_objects с декодированием objects_type в правильное выражение GRANT и выборкой по необходимым схемам.


>На bash + sqlplus пишется за час.

А нет ли способа сделать это ещё сложнее?

И что делать, если юзверь добавил новый view уже после GRANT? Давать юзверю права делать GRANT в базе и сказать, что это его обязанность?

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

9. "Oracle или MySQL?" 
Сообщение от DeadMustdie emailИскать по авторуВ закладки(??) on 24-Фев-05, 20:07  (MSK)
>all_objects с декодированием objects_type в правильное выражение
>GRANT и выборкой по необходимым схемам.

Оказывается, знающий человек. А жалуется на сущие семечки ;-(

>>На bash + sqlplus пишется за час.
>
>А нет ли способа сделать это ещё сложнее?

Вопрос привычки. Я в PL/SQL не силён, посему логику лично мне
проще писать на чём-нибудь другом. А SQL-ки тут нехитрые.

>И что делать, если юзверь добавил новый view уже после GRANT? Давать
>юзверю права делать GRANT в базе и сказать, что это его
>обязанность?

Весьма любопытно. То есть добавлять VIEW-хи ему можно, а настраивать
параметры доступа к ним - уже нельзя? По-хорошему свои объекты он
должен создавать в своей схеме, где у него есть все нужные права.
И если к созданным им объектам должны обращаться другие пользователи,
то права на доступ всё равно нужно выставлять от его имени.

Вообще у ORACLE достигнут вполне приличный компромисс между
юзабельностью и форсированием разумных правил обеспечения
безопасности. В MySQL IMHO сей баланс не выдержан.

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

10. "Oracle или MySQL?" 
Сообщение от ACCA Искать по авторуВ закладки(ok) on 06-Мрт-05, 09:19  (MSK)
>Весьма любопытно. То есть добавлять VIEW-хи ему можно, а настраивать
>параметры доступа к ним - уже нельзя? По-хорошему свои объекты он

Разумеется нет. Я хочу дать ему право добавить/отредактировать View. Мне совершенно не нравится идея отдавать ему право менять права доступа к любому объекту.


>Вообще у ORACLE достигнут вполне приличный компромисс между
>юзабельностью и форсированием разумных правил обеспечения
>безопасности. В MySQL IMHO сей баланс не выдержан.

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

А в Oracle мне приходится что-то всё время дописывать и подкручивать.

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

11. "Oracle или MySQL?" 
Сообщение от DeadMustdie emailИскать по авторуВ закладки(??) on 06-Мрт-05, 15:44  (MSK)

>Разумеется нет. Я хочу дать ему право добавить/отредактировать View.

Не в своей схеме? Тогда любой "bad guy" может устроить почти
любую пакость - в этой же схеме. Если же предполагается, что
"bad guy" туда не пролезет, то и вреда от настройки "хорошим"
пользователем необходимых аспектов доступа к созданному *им*
объекту вроде бы нет. Объём писанины, конечно, несколько
увеличивается.

>Мне совершенно не нравится идея отдавать ему право менять права
>доступа к любому объекту.

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

>
>В MySQL я просто иду по дереву - сервер->база->таблица->строка.
>Права наследуются, так что сказав один раз "можно" мне не нужно
>повторять его для каждой загогулины.
>
>А в Oracle мне приходится что-то всё время дописывать и подкручивать.

В ORACLE дерево другое: база -> схема -> таблица -> строка.
IMHO понятие прав "на базу в целом" отсутствует из-за того, что
оно есть слишком сильная вещь. Я не раз и не два видел, что один
экземпляр базы используется для хранения информации от нескольких
несвязанных друг с другом приложений. А если хоть одно из приложений
требует "отдай мне всю базу целиком", то такая конфигурация становится
небезопасной.

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

12. "Oracle или MySQL?" 
Сообщение от ACCA Искать по авторуВ закладки(ok) on 07-Мрт-05, 07:30  (MSK)
>>Разумеется нет. Я хочу дать ему право добавить/отредактировать View.
>
>Не в своей схеме? Тогда любой "bad guy" может устроить почти

Для Oracle - в своей. Для MySQL - в той, где у него достаточно прав. Фокус в том, что этим View должны пользоваться остальные.


>пользователем необходимых аспектов доступа к созданному *им*
>объекту вроде бы нет. Объём писанины, конечно, несколько
>увеличивается.

Увеличивается не только объём писанины, но и риск ошибки, когда права будут отданы "не тем парням".

>В ORACLE дерево другое: база -> схема -> таблица -> строка.

В Oracle дерево такое - tablespace->table->row. Я никак не могу дать права на чужую схему, мне приходится делать GRANT на каждый объект .

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

Пример конфигурации такого рода:

Пользователь A набивает данные в свою схему/базу. Попутно он создаёт методы доступа к данным, оформляя их как функции и View.

Пользователь B набивает данные в свою схему/базу, но подглядывает в данные пользователя A.

Поскольку данные критичные, нужно гарантировать, что пользователь A не сможет отдать доступ к новым объектам никому, кроме пользователя B.

В MySQL это делается просто -

GRANT CREATE, INSERT, UPDATE ON SCHEMA TO A
GRANT SELECT ON SCHEMA TO B


Насколько я (не)понимаю, в Oracle мне придётся делать чёрт знает что. A не сможет даже создать новый View в SCHEMA, если SCHEMA != A.

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

13. "Oracle или MySQL?" 
Сообщение от DeadMustdie emailИскать по авторуВ закладки(??) on 07-Мрт-05, 12:37  (MSK)
>Для Oracle - в своей. Для MySQL - в той, где у
>него достаточно прав. Фокус в том, что этим View должны пользоваться
>остальные.

Вполне пристойным вариантом может быть изготовление PL/SQL процедуры,
обеспечивающей создание и/или модификацию объектов в нужной схеме,
включая автоматическую простановку нужных прав.

Повторюсь: Вы разработали определённую схему работы с данными,
которая хорошо ложится на модель безопасности "по умолчанию",
принятую в MySQL, и плохо - на аналогичную модель, принятую в
ORACLE. Если бы Ваше приложение разрабатывалось изначально под
ORACLE, портация на MySQL вызвала бы никак не меньше боли в одном
месте (tm).

>Увеличивается не только объём писанины, но и риск ошибки, когда
>права будут отданы "не тем парням".

Там, где велик объём писанины, необходима автоматизация.
И в случае с ORACLE она вполне возможна.

>>В ORACLE дерево другое: база -> схема -> таблица -> строка.
>
>В Oracle дерево такое - tablespace->table->row. Я никак не могу дать
>права на чужую схему, мне приходится делать GRANT на каждый объект .

Есть такое понятие как 'shared schema'. AFAIK пользователям на неё
можно назначить комплект прав "по умолчанию".

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

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

>Пользователь A набивает данные в свою схему/базу. Попутно он
>создаёт методы доступа к данным, оформляя их как функции и View.
>
>Пользователь B набивает данные в свою схему/базу, но подглядывает
>в данные пользователя A.
>
>Поскольку данные критичные, нужно гарантировать, что пользователь A
>не сможет отдать доступ к новым объектам никому, кроме пользователя B.
>
>В MySQL это делается просто -
>
>GRANT CREATE, INSERT, UPDATE ON SCHEMA TO A
>GRANT SELECT ON SCHEMA TO B
>
>
>Насколько я (не)понимаю, в Oracle мне придётся делать чёрт знает что. A
>не сможет даже создать новый View в SCHEMA, если SCHEMA !=
>A.

Скорее всего, нужно будет оформлять описанную выше логику в хранимые
процедуры, которые и будут использоваться для создания и модифицирования
объектов схемы пользователем A. См. "Oracle® Database Security Guide",
раздел "5 Authorization: Privileges, Roles, Profiles, and Resource
Limitations", подразделы "Procedure Privileges", "Procedure Execution
and Security Domains", "Definer's Rights", "Invoker's Rights".

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

14. "Oracle или MySQL?" 
Сообщение от ACCA Искать по авторуВ закладки(ok) on 09-Мрт-05, 13:10  (MSK)
>Повторюсь: Вы разработали определённую схему работы с данными,
>которая хорошо ложится на модель безопасности "по умолчанию",

Если бы я это разрабатывал. Сделано людьми, для которых "безопасность" - слово из газет. У них проблема решена очень просто - всем пользователям даются все права на уровне сервера. Попытки навести порядок до сих пор безуспешны.


>принятую в MySQL, и плохо - на аналогичную модель, принятую в
>ORACLE. Если бы Ваше приложение разрабатывалось изначально под

Иерархическая модель раздачи прав доступа не специфична для MySQL. Эта идеология используется в файловых системах, например NetWare.

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


>Есть такое понятие как 'shared schema'. AFAIK пользователям на неё
>можно назначить комплект прав "по умолчанию".

Спасибо за наводку!

То есть вопрос теперь формулируется так - стоят ли удобства Enterprise Server геморроя с его установкой для трёх пользователей?


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

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

Я ввожу "свои", могу править "групповые" и читать "общие".


>объектов схемы пользователем A. См. "Oracle® Database Security Guide",
>раздел "5 Authorization: Privileges, Roles, Profiles, and Resource

THNX, я пока пошёл курить Managing Enterprise User Security.

Мне сильно не нравится идея обвешивать таблицы служебным кодом, который не сможет понять обезьяна-администратор.

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


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

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру