<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://www.dotnetzone.gr:443/cs/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Stored procedures : Your database API</title><link>https://www.dotnetzone.gr:443/cs/blogs/mental/archive/2006/06/07/13790.aspx</link><description>Έπεσα σ' ένα πολύ ενδιαφέρον άρθρο για το προαιώνιο δίλημμα : Stored procedures ή SQL κώδικας μέσα στην εφαρμογή ? όπου πιστεύω ότι ο συγγραφέας επιχειρηματολογεί ικανοποιητικά υπέρ της πρώτης προσέγγισης. Από τα πιο αγαπημένα μου : Οι stored procedures</description><dc:language>el</dc:language><generator>CommunityServer 2.1 SP3 (Build: 20423.1)</generator><item><title>Απ: Stored procedures : Your database API</title><link>https://www.dotnetzone.gr:443/cs/blogs/mental/archive/2006/06/07/13790.aspx#13809</link><pubDate>Thu, 08 Jun 2006 21:07:46 GMT</pubDate><guid isPermaLink="false">2622095e-976c-431a-859e-16783ec7ecd7:13809</guid><dc:creator>cap</dc:creator><description>Ενταξει. Ειναι ενα θέμα που σφάζονται παλληκάρια...Ομως ο συγγραφεύς δεν φαίνεται να ασχολείται με το θέμα του encapsulation οπως θα έπρεπε. Το όριο μεταξύ του encapsulation και της διάχυσης του business logic στο database layer ειναι δυσδιάκριτο. Δεν ειμαι υπερ του SQL-in-app αλλά από την άλλη μεριά με τις SPs ως API κινδυνεύουμε να έχουμε ένα μεγάλο μέρος του business logic εντός του data layer, ιδιαίτερα αν αυτές κάνουν περίπλοκα πράγματα.&lt;br&gt;</description></item><item><title>Απ: Stored procedures : Your database API</title><link>https://www.dotnetzone.gr:443/cs/blogs/mental/archive/2006/06/07/13790.aspx#13873</link><pubDate>Sun, 11 Jun 2006 22:17:41 GMT</pubDate><guid isPermaLink="false">2622095e-976c-431a-859e-16783ec7ecd7:13873</guid><dc:creator>Panagiotis Kontopoulos</dc:creator><description>Αυτό που σίγουρα πρέπει να κρύβουμε σε μια database είναι οι επιλογές που έγιναν με αποκλειστικό σκοπό τη βελτίωση του performance. Πράγματα όπως είναι π.χ. το de-normalization πινάκων, διπλοσυντηρώντας την ίδια πληροφορία ώστε να μπορούμε χωρίς joins να έχουμε την εικόνα που θέλουμε είναι καλοί υποψήφιοι για απόκρυψη πίσω από ένα ωραίο Database API. &lt;br&gt;&lt;br&gt;Επίσης - πάντα κατά τη γνώμη μου - όσο κι αν θα'θελα να ενημερώσω π.χ. τις τιμές λιανικής των προϊόντων που ανήκουν σε συγκεκριμένες κατηγορίες με έναν απόλυτα σωστό object oriented τρόπο, νομίζω ότι τελικά θα υπέκυπτα στις &amp;quot;σειρήνες&amp;quot; μιας stored procedure που θα έκανε την ίδια δουλειά σε μερικά δέκατα του δευτερολέπτου.  &lt;br&gt;&lt;br&gt;Κινδυνεύοντας να ανοίξω ένα διαφορετικό thread στη συζήτηση, γι' αυτό νομίζω ότι΄πλέον είμαι υπέρ της υλοποίησης Service Oriented συστημάτων τα οποία δεν διστάζουν να χρησιμοποιήσουν business objects είτε data objects προκειμένου να υλοποιήσουν τη λειτουργικότητά τους. &lt;br&gt;&lt;br&gt;&lt;br&gt;Τι λέτε ? Makes any sense ?&lt;br&gt;&lt;br&gt;&lt;br&gt;</description></item></channel></rss>