sqlschool.gr logo

articles

Articles of SQLschool.gr Team

Λίγα λόγια για τα database Schemas

Antonios Chatzipavlis
Thursday 01 July 2010

Αρκέτες φορές έχω δεχθεί ερωτήσεις σχετικά με τα database Schemas. Οι πιο δημοφιλείς ερωτήσεις είναι;

  1. Τι είναι τα Schemas;
  2. Ποιά είναι η πρακτική αξία τους;
  3. Γιατί τα έβαλαν στον SQL Server τόσο αργά; η Oracle τα έχει χρόνια τώρα!

Θα ξεκινήσω με την τελευταία.

Μπορεί τα schemas να εμφανίστηκαν από τον SQL Server 2005 αλλά αυτό δεν σημαίνει ότι δεν υπήρχαν και πριν. Υπήρχαν αλλά δεν ήταν “ορατά”. Στην πραγματικότητα με το που έφτιαχνες έναν user, αυτόματα δημιουργόνταν το αντίστοιχο schema.

Στην Oracle υπήρχαν, αλλά ο σκοπός τους ήταν καλύψουν μια ανάγκη που βασικά δεν την είχαμε, ούτε την έχουμε, στον SQL Server. Όπως θα γνωρίζεται κάθε database στην Oracle είναι ένα διαφορετικό service. Έτσι εάν θέλω να έχω μια βάση για το ERP μου, μια βάση για το Web Site μου, και μία βάση για κάτι άλλο, θα πρέπει να έχω τρία διαφορετικά services να τρέχουν. Στο SQL Server δεν το έχουμε ανάγκη αυτό, διότι με ένα service μπορώ να έχω 32767 διαφορετικές βάσεις. Με την χρήση λοιπόν των schemas στην Oracle έλυνα το παραπάνω θέμα. Έφτιαχνα μια βάση στην οποία έφτιαχνα τα αντίστοιχα schemas μέσα σε αυτή ώστε να καλύψω τις τρεις διαφορετικές δομές που είχα σε κάθε βάση.

Η εμφάνιση των Schemas στον SQL Server είναι για να λύσουν άλλα θέματα. Αλλά ας πάρουμε τα πράγματα από την αρχή.

Ένα Schema στον SQL Server δεν είναι τίποτα άλλο από ένα named container για τα database objects (tables,views,stored procedures κλπ).

Βασικός λόγος που έκαναν την εμφάνιση τους τα Schemas από τον SQL Server 2005 και μετά ήταν για να λύσουν ένα βασικό administration πρόβλημα.

Έστω λοιπόν ότι έχω τον χρήστη Nasos. Δεν είναι administrator, δεν είναι database owner, έχει όμως δικαιώμα να φτιάχνει tables. Έστω ότι αυτός έφτιαξε τους πίνακες Ν1 και Ν2. Άρα έχω dbname.Nasos.N1 και dbname.Nasos.N2.

Εάν τώρα έσβηνα τον user Nasos είτε κατά λάθος είτε διότι έπρεπε, επειδή ο Νάσος έφυγε από την εταιρεία, στις προηγούμενες εκδόσεις τα object αυτά έμεναν ορφανά, το αποτέλεσμα ήταν ότι είτε δεν λειτουργούσαν stored procedures που πατούσαν πάνω σε αυτά, είτε δεν μπορούσα να προσπελάσω απευθείας, και έπρεπε να μπω στην διαδικασία να πάρω το ownership με ότι αυτό συνεπάγεται.

Από τον SQL Server 2005 και μετά αυτό δεν συμβαίνει διότι πολύ απλά οι πίνακες αυτοί δεν ανήκουν στον user αλλά στο Schema.

Αυτός ήταν και ο βασικός λόγος που σαν DBA δεν έδινα δικαιώματα στο user να φτιάχνει δικά του objects ή αν πραγματικά ήθελα να κάνω κάτι τέτοιο έβαζα όλους τους χρήστες με ένα user name.

Κάθε user ανήκει σε κάποιο Schema. Ακόμα και αν δεν πω κατά την δημιουργία του user στην βάση σε ποιο Schema ανήκει, by default αυτός θα ανήκει στο Schema dbo.

Επίσης όταν δημιουργώ ένα object πχ έναν πίνακα και δεν λέω κατά την στιγμή της δημιουργίας του σε ποιο Schema αυτό θα ανήκει, by default αυτό πάει στο Schema στο οποίο ανήκει ο user που το δημιούργησε.

Κάθε Schema έρχεται και κάθεται μεταξύ του database level του object level στην ιεραρχία του SQL Server. Αυτό σημαίνει ότι μπορώ να έχω περισσότερες δυνατότητες στον ορισμό του security πάνω στα objects της βάσης μου. Κάποια στιγμή θα σας πω για το security στον SQL Server και θα σας το εξηγήσω καλύτερα.

Κάθε Schema επίσης έχει συγκεκριμένο owner. O οποίος μπορεί να είναι είτε συγκεκριμένος user είτε database role είτε application role.

To Schema πλέον αντικαθιστά τον owner στο multi-part object name. Αυτό σημαίνει ότι στο παράδειγμα SELECT * FROM Northwind.antonis.Customers μέχρι την έλευση του SQL Server 2005 λέγαμε ότι ο antonis είναι ο χρήστης τώρα δεν είναι ο χρήστης αλλά το schema.

Μερικές χρήσιμες συμβουλές για τα Schemas

  1. Ομαδοποίηση αντικειμένων σύμφωνα με το σκοπό τους πχ schema το οποίο περιέχει όλα τα αντικείμενα που αφορούν μια συγκεκριμένη ενότητα (π.χ web site).
  2. Διαχείριση του security σε επίπεδο βάσης με την χρήση των Schemas. Δηλαδή αντί να δίνω δικαιώματα σε επίπεδο χρήστη δίνω σε επίπεδο schema και ο χρήστης κληρονομεί αυτά μιας και ανήκει στο schema αυτό.
  3. Καλό είναι να μην είναι όλος ο κόσμος Schema owner. Ένας χρήστης είναι το ιδανικό.
  4. Επισης καλό θα είναι να μην είναι ο dbo ο owner για τα schemas τα οποία έχω μέσα στην βάση μου.

Αυτά τα λίγα για τα Schemas και την πρακτική τους αξία στον SQL Server. Ελπίζω να έδωσα απαντήσεις στα ερωτήματα σας.

Antonios Chatzipavlis

Antonios Chatzipavlis

Antonios is a Data Solutions Consultant and Trainer. He has been working in IT since 1988. In his career, he has worked as senior developer, IT Manager, Solutions Architect and IT Consultant. Since 1995 he has been devoted on new technologies and software development tools, mainly by Microsoft, either by training company staff and colleagues or assisting them in design, development and implementation as a consultant or chief developer. He has focused in Databases and Data Science since 1995. He specialized in Microsoft SQL Server since version 6.0 in areas like SQL Server Internals, Database Design and Development, Business Intelligence and in 2010 he has started working with Azure Data Platform, NoSQL databases, Big Data Technologies and Machine Learning. He is an active member of many IT communities in Greece, answering colleagues' questions and writing articles in his web site. He is the owner of SQLschool.gr which is a community portal with a lot of information about Microsoft SQL Server. He has been a Microsoft Certified Trainer (MCT) since 2000. Microsoft honored him as MVP on Data Platform due to his activities in SQL Server since 2010. He holds a large number of Microsoft Certifications and Microsoft SQL Server Certifications since version 6.5.

Episode

First look: SQL Database in Microsoft Fabric

image

More Episodes...

Tip

What's New in SQL Server 2022 - Episodes

More Tips...

Become a member

If you want to receive updates from us become a member to our community.

Connect

Explore

Learn


sqlschool.gr © 2010-2024 All rights reserved

This site uses cookies for operational and analytics purposes only. By continuing to browse this site, you agree to their use.