RE: [SQL] Good Optimization
От | John Ridout |
---|---|
Тема | RE: [SQL] Good Optimization |
Дата | |
Msg-id | 000501bec9f9$b09be900$0301010a@johnridout обсуждение исходный текст |
Ответ на | Good Optimization ("Ansley, Michael" <Michael.Ansley@intec.co.za>) |
Ответы |
Re: [SQL] Good Optimization
|
Список | pgsql-sql |
Hi, I'm developing on PostgreSQL. The lack of stored procedures which return a rowset is a major disadvantage for PostgreSQL. Completely aside from the performance issue are application security and the architecture of the information system. I'll give an example so I'm what I'm talking about. :-) Based on the database user's identity I chose which rowset to return. We can't allow someone to peek at someone else's data. (They may be a few more steps before I decide which rowset to return.) The alternatives are not pretty. 1. Allow the client to chose which rowset is returned. This is means no security so its not really an option. 2. Create a database function which given the primary key of a table returns true or false for whether the current usermay return this row. Use this function in a view. Massively inefficient. 3. Adopt a 3-tier architecture for all parts of the system. Right down to the most trivial data entry and reporting. Sonow we have an unnecessarily complex system. I.e. it will take longer, cost more and have more bugs. Of course theywon't be my bugs. ;-) I have a small question where do I get started hacking PostgreSQL? I'll have plenty of time to get started round about September. In the meantime what homework do you suggest? Clustering!? Can we have a transaction log first? Regards John Ridout. P.S. Send me your tips for programming PostgreSQL. So far I have received hints and tips for Query optimization. Passing more than 8 arguments to a function.
В списке pgsql-sql по дате отправления: