Почему схемы базы данных использования?
На окнах работы проклятий из поля, ncurses не делают, и для индикатора выполнения проклятия должны быть достаточными. Так, используйте проклятия вместо ncurses.
кроме того, оба проклятия и ncurses являются тончайшими обертками вокруг c библиотеки - который означает, что Вам действительно не нужны определенные для Ruby учебные руководства.
Однако на сайт для PickAxe можно загрузить все примеры кода для книги. Файл "ex1423.rb" содержит демонстрацию проклятий, которая играет Вонь - который должен дать Вам много материала для получения Вас движение.
4 ответа
У вас есть основное преимущество с точки зрения логической группировки объектов вместе и разрешения установки разрешений на уровне схемы.
Это действительно усложняет программирование, поскольку вы всегда должны знать из какой схемы вы собираетесь что-то получить - или полагаться на правильную схему пользователя по умолчанию. Точно так же вы можете затем использовать это, чтобы разрешить одно и то же имя объекта в разных схемах, так что код будет записывать только для одного объекта, в то время как схема, которую пользователь по умолчанию определяет, какой из них является.
Я бы не сказал, что это было таким обычным явлением, как ни странно, большинство людей все еще отбрасывают все в схеме dbo.
Для меня они могут вызвать больше проблем, потому что они нарушают цепочку владения .
Пример:
Хранимая процедура tom.uspFoo использует table tom.bar легко, но потребуются дополнительные права на dick.AnotherTable . Это означает, что я должен предоставить права выбора на dick.AnotherTable вызывающим tom.uspFoo ... который предоставляет прямой доступ к таблице.
Если я что-то полностью не упустил. ...
Edit, февраль 2012 г.
Я задал вопрос по этому поводу: SQL Server: Как разрешить схемы?
Ключ - «тот же владелец»: так что если dbo владеет схемами dick и tom , тогда применяется цепочка владения . Мой предыдущий ответ был неправильным.
Это может быть полезно по нескольким причинам:
совместное использование данных между несколькими (экземплярами из) приложение. Это могло быть случай, если у вас есть группа ссылок данные, которые используются совместно приложения и группа данных что характерно для данного экземпляра. Будьте осторожны, чтобы не иметь циклических ссылок между объектами в разных схемах. Это означает отсутствие внешнего ключа от объекта в схеме 1 к другому объекту в схеме 2 И иметь другой внешний ключ от схемы 2 до схемы 1 в других объектах.
разделение данных: позволяет хранить данные на разных серверах
- как вы упомянули, контроль доступа на уровне БД
Я не знаю других возможных причин, кроме организации и разрешений. Этого недостаточно? :)
Для справки - я всегда использую одну схему - но потом я создаю веб-приложения, и есть только один пользователь.
Обновление, 10 лет спустя!
Есть еще одна причина, фактически. У вас могут быть «копии» вашей схемы для разных целей. Например, представьте, что вы создаете платформу для блогов. Люди могут зарегистрироваться и создавать свои собственные блоги. Каждому блогу нужна таблица для сообщений, тегов, изображений, настроек и т. Д. Один из способов сделать это - добавить столбец
blog_id для каждой таблицы и используйте его, чтобы различать блоги. Или ... вы можете создать новую схему для каждого блога и новые таблицы для каждого из них. Это дает несколько преимуществ:
- Упрощение программирования. Вы просто выбираете подходящую схему в начале, а затем пишете все свои запросы, не беспокоясь о том, чтобы забыть добавить
, где blog_id = @ currentBlogгде-то. - Вы избегаете целого класса потенциальных ошибок, когда внешний ключ в одном блоге указывает на объект в другом блоге (случайное раскрытие данных!)
- Если вы хотите стереть блог, вы просто бросаете схема со всеми таблицами в ней. Намного быстрее, чем поиск и удаление записей из десятков различных таблиц (тем не менее в правильном порядке!)
- Производительность каждого блога зависит только (ну, в основном, в любом случае) от того, сколько данных находится в , что блог.
- Экспортировать данные проще - просто выгрузите все объекты в схеме.
Конечно же, есть и недостатки.
- Когда вы обновляете свою платформу и вам нужно внести изменения в схему, вам нужно обновить каждый блог отдельно.
- То же самое и с исправлением поврежденных данных, если это произойдет по какой-либо причине.