А что, в MS SQL нет пакетов?
Что за "пакеты"?
набор процедур. Можно провести грубую аналогию с .нетной сборкой.
Схема - это не то в Sql Server?
набор процедурну это слишком грубо
в пакеты могут входить процедуры, функции, объявления типов и переменные
у переменных фича в их сохранении в пределах сессии
тоесть я могу обращаться к разным процедурам (в разных пакетах) в пределах сесии и при этом не передавать каждый раз в параметрах нужную всем процедурам переменную
Схема - это не БД (как в MySQL)?
БД - это следующий уровень абстракции, над схемой.
В схеме нет юзеров, например, а в БД есть.
Вообще, схема - это доп. абстракция для группирования сущностей и контроля прав доступа к ним.
В схеме нет юзеров, например, а в БД есть.
Вообще, схема - это доп. абстракция для группирования сущностей и контроля прав доступа к ним.
БД - это следующий уровень абстракции, над схемой.ты точно не ошибаешься?
В схеме нет юзеров, например, а в БД есть.
я MSSQL не знаю, но слышал что там:
юзеры есть в СУБД
а вот схема и БД - это одно и тоже
Схема - это не то в Sql Server?нет
порылся в гугле
в MS SQL и вправду нет пакетов
печально
// блин, ну почему по oracle гугл выдает тонны полезной информации на любой запрос, а для поиска инфы по MS SQL или DB2 нужно ломать голову над составлением запроса?
Да?
Вот в mysql есть БД, в них есть таблицы...
А в MySQL Query Browser пункт меню "создать новую БД" называется "create new schema".
Вот в mysql есть БД, в них есть таблицы...
А в MySQL Query Browser пункт меню "создать новую БД" называется "create new schema".
> ну почему по oracle гугл выдает тонны полезной информации на любой запрос
потому что oracle сложная штука для понимания которой необходимо тонна документации?
потому что oracle сложная штука для понимания которой необходимо тонна документации?
Пишу про 2005 сервер.
На одном сервере (SQL Server Instance) есть логины и базы данных.
В каждой БД есть юзеры и схемы.
Юзеру может соответствовать один логин на сервере.
В каждой схеме содержатся таблицы, хранимки и т.п.
Дефолтная схема - dbo.
Права можно давать на отдельные сущности отдельным юзерам или группам, можно на целые схемы, в которые объединены сущности.
На одном сервере (SQL Server Instance) есть логины и базы данных.
В каждой БД есть юзеры и схемы.
Юзеру может соответствовать один логин на сервере.
В каждой схеме содержатся таблицы, хранимки и т.п.
Дефолтная схема - dbo.
Права можно давать на отдельные сущности отдельным юзерам или группам, можно на целые схемы, в которые объединены сущности.
написал вроде хорошо, а в чем отличие схемы от бд так и не объяснил
ты говоришь что есть три абстракции
1) сервер, он же инстанс, он же субд
2) бд
3) схема
отличия первого пункта от второго и третьего понятны всем
отличия второго и третьего непонятны, ты говоришь что отличие в юзерах
ты говоришь что юзеры принадлежат бд, означает ли это что в разных бд разные юзеры?
тоесть юзера db1.user1 нету в бд bd2
ты говоришь что есть три абстракции
1) сервер, он же инстанс, он же субд
2) бд
3) схема
отличия первого пункта от второго и третьего понятны всем
отличия второго и третьего непонятны, ты говоришь что отличие в юзерах
ты говоришь что юзеры принадлежат бд, означает ли это что в разных бд разные юзеры?
тоесть юзера db1.user1 нету в бд bd2
Ага. Юзеры в БД, не в схемах.
Юзер может владеть схемой. Может быть, даже несколькими (точно не знаю).
Юзер может владеть схемой. Может быть, даже несколькими (точно не знаю).
для лучшего восприятия, приведу отрывок из Books Online
What is a schema?
A schema is a collection of database entities that form a single namespace. A namespace is a set in which every element has a unique name.
For example, to avoid name collisions, no two tables in the same schema can have the same name. Two tables can have the same name only if they are in separate schemas.
From SQL Server 2000 to SQL Server 2005
Although SQL Server 2000 has a CREATE SCHEMA statement, it does not actually create schemas in the sense defined above. In SQL Server 2000, database users and schemas are implicitly connected. Every database user is the owner of a schema that has the same name as the user. And an object's owner is effectively identical to the owner of the schema that contains it. Thus, the "schema" of a fully-qualified name in SQL Server 2000 is also a user in the database. For this reason, prior to dropping a user from a SQL Server 2000 database, the administrator needed to drop all the objects owned by that user or change their owner. Consider a SQL Server 2000 database containing this object:
accounting.ap.george.reconciliation
This object is owned by user "george". If the administrator needs to delete user "george", she must first delete this object or change its owner. In the latter case, it might be renamed as follows:
accounting.ap.sandra.reconciliation
Transferring ownership of the object also changes its fully-qualified name. Any code that refers to accounting.ap.george.reconciliation must be updated to reflect the name change.
In SQL Server 2005, schemas exist independently of the database user that creates them. Ownership of schemas can be transferred without changing their names. And objects can be created in schemas with user-friendly names that clearly indicate their function. For example, rather than accounting.ap.sandra.reconciliation you can create a schema called accounting.ap.invoice.reconciliation. This name need not be changed when a user is dropped from the database, because "invoice" is not a user. This simplifies the work of database administrators and developers.
Benefits of User – Schema Separation
The abstraction of database users from schemas provides several benefits to administrators and developers.
Multiple users can own a single schema via membership in roles or Windows groups. This extends the familiar functionality allowing roles and groups to own objects.
Dropping database users is greatly simplified.
Dropping a database user does not require the renaming of objects contained by that user's schema. Thus it is no longer necessary to revise and test applications that refer explicitly to schema-contained objects after dropping the user that created them.
Multiple users can share a single default schema for uniform name resolution.
Shared default schemas allow developers to store shared objects in a schema created specifically for a specific application, rather than in the DBO schema.
Permissions on schemas and schema-contained objects can be managed with a higher degree of granularity than in earlier releases.
Fully-qualified object names now have four parts: server.database.schema.object.
What is a schema?
A schema is a collection of database entities that form a single namespace. A namespace is a set in which every element has a unique name.
For example, to avoid name collisions, no two tables in the same schema can have the same name. Two tables can have the same name only if they are in separate schemas.
From SQL Server 2000 to SQL Server 2005
Although SQL Server 2000 has a CREATE SCHEMA statement, it does not actually create schemas in the sense defined above. In SQL Server 2000, database users and schemas are implicitly connected. Every database user is the owner of a schema that has the same name as the user. And an object's owner is effectively identical to the owner of the schema that contains it. Thus, the "schema" of a fully-qualified name in SQL Server 2000 is also a user in the database. For this reason, prior to dropping a user from a SQL Server 2000 database, the administrator needed to drop all the objects owned by that user or change their owner. Consider a SQL Server 2000 database containing this object:
accounting.ap.george.reconciliation
This object is owned by user "george". If the administrator needs to delete user "george", she must first delete this object or change its owner. In the latter case, it might be renamed as follows:
accounting.ap.sandra.reconciliation
Transferring ownership of the object also changes its fully-qualified name. Any code that refers to accounting.ap.george.reconciliation must be updated to reflect the name change.
In SQL Server 2005, schemas exist independently of the database user that creates them. Ownership of schemas can be transferred without changing their names. And objects can be created in schemas with user-friendly names that clearly indicate their function. For example, rather than accounting.ap.sandra.reconciliation you can create a schema called accounting.ap.invoice.reconciliation. This name need not be changed when a user is dropped from the database, because "invoice" is not a user. This simplifies the work of database administrators and developers.
Benefits of User – Schema Separation
The abstraction of database users from schemas provides several benefits to administrators and developers.
Multiple users can own a single schema via membership in roles or Windows groups. This extends the familiar functionality allowing roles and groups to own objects.
Dropping database users is greatly simplified.
Dropping a database user does not require the renaming of objects contained by that user's schema. Thus it is no longer necessary to revise and test applications that refer explicitly to schema-contained objects after dropping the user that created them.
Multiple users can share a single default schema for uniform name resolution.
Shared default schemas allow developers to store shared objects in a schema created specifically for a specific application, rather than in the DBO schema.
Permissions on schemas and schema-contained objects can be managed with a higher degree of granularity than in earlier releases.
Fully-qualified object names now have four parts: server.database.schema.object.
О, круто.
Похоже, в MySQL это не так?
Похоже, в MySQL это не так?
А ХЗ
Оставить комментарий
pitrik2
в oracle и db2 естьа где еще есть? в постгресе есть?