EkranlarScreens
PostgreSQL betikleri sözdizimi ağacına dönüştürülerek çözümlenir. Aynı yönetişim akışı, aynı kural seti, PostgreSQL'e uyarlanmış karşılıklarıyla çalışır. PostgreSQL scripts are analysed by turning them into a syntax tree. The same governance flow and the same rule set apply, through equivalents adapted to PostgreSQL.
Betik, PostgreSQL dilbilgisine göre bir ağaca dönüştürülür ve kurallar bu ağaç üzerinde çalışır. Tırnaklı nesne adları, şema önekleri ve iç içe sorgulardaki hedefler doğru konumla birlikte raporlanır. Bazı yardımcı kontroller metin eşleşmesiyle yapılır.The script is turned into a tree according to PostgreSQL grammar, and the rules run on that tree. Quoted identifiers, schema prefixes and targets inside nested queries are reported with their correct position. Some auxiliary checks use text matching.
Kural setindeki her madde her veritabanında birebir aynı şekilde ifade edilmez. Bir kuralın hangi veritabanı tiplerinde geçerli olduğu tanımlıdır; PostgreSQL'de karşılığı olmayan bir kural o tarafta hiç çalışmaz, karşılığı olan kural PostgreSQL'e uygun biçimde uygulanır.Not every item in the rule set is expressed identically on every database. Each rule declares the database types it applies to; a rule with no PostgreSQL equivalent simply does not run there, and one that does have an equivalent is applied the PostgreSQL way.
Kritik nesne erişimi ve şema değişikliği, WHERE içermeyen veri değişikliği, TRUNCATE, yetki değişikliği ve şema öneki eksikliği PostgreSQL tarafında da yakalanır.Critical object access and schema change, data changes without a WHERE clause, TRUNCATE, permission changes and missing schema prefixes are caught on PostgreSQL as well.
Geri alma betiği üretimi PostgreSQL için de vardır. Betik, üretim dışı bir sunucuda, sonunda geri alınan bir transaction içinde denenebilir ve sonuç talebe iliştirilir; bu deneme üretim koşullarının tam benzetimi değildir.Rollback script generation exists for PostgreSQL too. A script can be tried on a non production server inside a transaction that is rolled back at the end, and the result is attached to the request; the trial is not a full simulation of production.
Bir talebin yolu veritabanı tipine göre değişmez: doğrulama, risk bandı, politika, onay, çalıştırma ve denetim. Değişen tek şey, betiği hangi ayrıştırıcının çözümlediğidir.
The path of a request does not change with the database type: validation, risk band, policy, approval, execution and audit. The only thing that changes is which parser analyses the script.
Ayrıştırıcı, talebin hedef sunucusundaki veritabanı tipinden seçilir. Bu yüzden karışık ortamlarda onay kuralınız tek kalır: SQL Server için ayrı, PostgreSQL için ayrı bir yönetişim modeli kurmanız gerekmez.
The parser is chosen from the database type of the request's target server. In a mixed estate this keeps your approval rule single: you do not need one governance model for SQL Server and another for PostgreSQL.
Kapsam notu: PostgreSQL burada yönetilen hedef veritabanıdır. Ürünün kendi kayıt veritabanı SQL Server 2022 ya da üstünde çalışır.
Scope note: PostgreSQL is a managed target database here. The product keeps its own records on SQL Server 2022 or later.