sql >> Databasteknik >  >> RDS >> Oracle

Offentliga synonymer kontra schema.objektmönster

Offentliga synonymer tjänar ett mycket specifikt syfte; de gör att ett objekt kan refereras av alla användare - förutsatt att de har lämpliga privilegier. Om du någon gång i framtiden kanske vill ändra hur en specifik användare ser ett objekt så är offentliga synonymer inte rätt väg att gå.

De använder också ett specifikt objektnamn för hela databasen. Det faktum att det finns en offentlig synonym hindrar dig dock inte från att skapa ett objekt med samma namn. Detta kan vara otroligt förvirrande.

Anta till exempel att du har ett test för proceduren och ett schema emp . Försöker köra emp.test kommer inte att fungera eftersom du redan har en offentlig synonym empbordet .

Tom Kyte , verkar har skrivit en antal artiklar om detta.

När det gäller prestandaaspekten verkar de föreslå att en offentlig synonym över en privat synonym kommer att resultera i en lite minskning av prestanda . Men att använda en synonym istället för ingen synonym kommer också att resultera i en liten minskning av prestanda. Detta tyder på att om varenda dator är värdefullt bör du inte använda synonymer alls.

Sammantaget tror jag att detta betyder att du bör undvika offentliga synonymer om möjligt. Om du behöver man använder då förstås en, de finns trots allt av en anledning, men om man inte gör det, vad är poängen med att ha en? scott.emp konstruktionen är tydlig, visar dig exakt vilket schema och objekt du refererar till utan någon möjlighet för misstolkningar, varken av dig själv eller någon annan som kommer ny till databasen och koden.

Snabb poäng. Du säger det inte uttryckligen men formuleringen av din fråga verkar antyda att du skapar ett schema för varje användare. Det verkar som att det skulle vara enormt förvirrande...




  1. bind_param() endast nödvändig för användarinmatade värden eller alla?

  2. Hur räknar man antalet icke-konsekutiva värden i en kolumn med SQL?

  3. Visa flera värden för en kolumn i en rad (SQL Oracle)

  4. Dynamiska databastabeller i django