met uitzondering van SQL in postgres talen

stemmen
6

Ik heb met behulp van PostgreSQL is een beetje de laatste tijd, en een van de dingen die ik denk dat cool is dat u iets anders dan SQL talen kunnen gebruiken voor scripting functies en wat al niet. Maar wanneer is dit werkelijk nuttig?

Bijvoorbeeld, de documentatie zegt dat de belangrijkste toepassing voor PL / Perl is dat het vrij goed in het bewerken van tekst. Maar is dat niet meer iets dat moet worden geprogrammeerd in de applicatie?

Ten tweede is er geen geldige reden om een ​​niet-vertrouwde taal te gebruiken? Het lijkt alsof waardoor het zo dat iedere gebruiker kan uitvoeren elke operatie zou een slecht idee op een productie-systeem.

PS. Bonuspunten als iemand kan maken PL / LOLCODE lijken nuttig.

De vraag is gesteld op 02/09/2008 om 14:32
bron van user
In andere talen...                            


7 antwoorden

stemmen
1

Deze dagen, elke "unieke" of "cool" -functie in een DBMS maakt me ongelooflijk nerveus. Ik breken in een uitslag en hebben te stoppen met werken totdat de jeuk verdwijnt.

Ik haat te worden opgesloten in een platform onnodig. Stel dat je een groot deel van uw systeem te bouwen in PL / Perl in de database. Of in C # binnen SQL Server, of PL / SQL in Oracle, zijn er tal van voorbeelden *.

Nu ben je opeens ontdekken dat uw gekozen platform niet schaal. Of is niet snel genoeg. Of zoiets. Erger nog, er is een nieuwe jongen op de database blok (iets als MonetDB, CouchDB, Cache, zeg maar veel koeler) dat al je problemen zou oplossen (zelfs als uw enige probleem, als de mijne, is het hebben van een uncool databse platform). En je kunt niet overschakelen naar het zonder hercoderen van de helft van je applicatie.

(* Toegegeven, de betaalde producten zijn tot op zekere hoogte op zoek naar u in vergrendelen door het overtuigen dat je hun unieke functies te gebruiken, dat is niet een beschuldiging die direct kunnen worden geuit op de gratis providers, maar het effect is hetzelfde).

Dus dat is een rant over het eerste deel van de vraag. Hart-voelde, dat wel.

is er geen geldige reden om een ​​niet-vertrouwde taal te gebruiken? Het lijkt alsof waardoor het zo dat iedere gebruiker kan elke handeling uit te voeren een slecht idee zou zijn

Mijn God, ja het doet! Een soort van "Perl-injectie aanval"? Bijna de moeite waard is om te zien wat er gebeurt, zou ik gedacht hebben.

Filosofische redenen hierboven geschetste Ik denk dat ik doorgeven aan de PL / LOLCODE uitdaging. Hoewel ik was enigszins verbaasd om te ontdekken dat het een link naar iets gebleven.

antwoordde op 02/09/2008 om 14:54
bron van user

stemmen
3

"Is niet dat [tekst manipulatie] meer van iets dat in de aanvraag moet worden geprogrammeerd?"

Meestal wel, ja. De algemeen aanvaarde " three-tier " applicatie ontwerp voor databases zegt dat uw logica moet in de middelste laag, tussen de client en de database. Echter, soms wat je nodig hebt enige logica in een trigger of moeten index op een functie, te eisen dat een code in de database worden geplaatst. In dat geval worden alle gebruikelijke "welke taal moet ik gebruiken?" vragen komen.

Als je alleen een beetje logica nodig heeft, moet de meest draagbare taal waarschijnlijk worden gebruikt (pl / pgsql). Als u nodig hebt om een ​​aantal ernstige programmering al doen, zou je beter af zijn met behulp van een meer expressieve taal (misschien pl / robijn). Dit zal altijd een afweging te zijn.

"Er is geen geldige reden om een ​​niet-vertrouwde taal te gebruiken?"

Zoals hierboven, ja. Nogmaals, waardoor directe toegang tot bestanden (bijvoorbeeld) in uw middelste laag is het beste als mogelijk, maar als je nodig hebt om dingen af ​​op basis van triggers te vuren (die mogelijk toegang hebben tot gegevens die niet direct beschikbaar om uw middelste laag nodig hebt), dan niet-vertrouwde moet je talen. Het is niet ideaal, en moet in het algemeen worden vermeden. En heb je zeker nodig hebt om toegang te bewaken om het.

antwoordde op 02/09/2008 om 15:17
bron van user

stemmen
5

@Mike: deze manier van denken maakt me nerveus. Ik heb vele malen gehoord "dit moet oneindig draagbaar zijn", maar als de vraag wordt gesteld: doe je dat eigenlijk voorzien dat er een portering zal zijn? het antwoord is nee.

Vasthouden aan de kleinste gemene deler kan echt pijn prestaties, evenals de introductie van abstractie lagen (ORM, PHP BOB, etc). Mijn mening is:

  • Evalueer realistisch als er behoefte is om meerdere RDBMS ondersteunen. Bijvoorbeeld als u een open source web applicatie schrijven, is de kans groot dat je nodig hebt om MySQL en PostgreSQL ondersteuning van ten minste (indien niet MSSQL en Oracle)
  • Na de evaluatie, maken het grootste deel van het platform dat u besloten

En tussen haakjes: je bent het mengen van relationele met niet-relatie databases (CouchDB is niet een RDBMS vergelijkbaar is met Oracle bijvoorbeeld), verder als voorbeeld het punt dat de gevoelde behoefte aan draagbaarheid is vele malen sterk overschat.

antwoordde op 02/09/2008 om 17:56
bron van user

stemmen
1

Vanuit mijn perspectief, ik denk dat het antwoord is 'het hangt'.

Er is een argument dat manipulatie van de gegevens behoort in de database laag, zodat de business logica hoeft niet al te veel zorgen over de manier waarop de manipulatie gebeurt te zijn, weet alleen dat het heeft.

Een andere zeer goede reden om gegevens te verwerken over de db laag is als de hoeveelheid gegevens die worden verwerkt betekent dat de bandbreedte van het netwerk zal een probleem worden. Ik had eens tot zeer grote hoeveelheden gegevens te categoriseren. Verwerking van deze in de toepassingslaag werd ernstig beperkt door de tijd die nodig is om de data over te dragen over het netwerk voor verwerking.

Ik schreef toen een binning algoritme in PL / pgsql en het werkte veel sneller.

Over onbetrouwbare talen, hoorde ik een podcast Josh Berkus (a postgres advocaat) die een toepassing van postgresql die in data bracht MySQL kader van de verwerking, zodat de communicatie zelf gebeurde door de postgres server besproken. Ik herinner me niet de volledige informatie, ik denk dat het was op de FLOSS Weekly podcast dat is nogal een interessante discussie over de geschiedenis van PostgreSQL en enkele van de problemen die het te zetten.

antwoordde op 05/09/2008 om 12:18
bron van user

stemmen
0

Ik denk dat de meeste extra talen worden aangeboden, zodat als u in die taal op een regelmatige basis te ontwikkelen, kunt u zich gerust schriftelijk db functies voelen, triggers, enz. Het nut van deze functies is om een ​​controle over data zo dicht mogelijk bij de gegevens en verstrekt mogelijk.

antwoordde op 18/09/2008 om 15:51
bron van user

stemmen
1

De niet-vertrouwde versies van de procedurele talen biedt u toegang op I / O op het systeem. Dit kan van pas komen als je een trekker of iets nodig hebt stuur dan een e-mail of verbinding maken met een socket server om een ​​popup-melding te verzenden. Er zijn vele toepassingen voor dit soort dingen, en vanwege postgresql vergrendelingsniveaus u blikjes veilig dit soort dingen doen. U kunt checkpoints in de functie te zetten, dus als de transactie niet door de e-mail of wat dan ook zal niet naar buiten. Het leuke aan dit te doen is het niet langer op de logica van de klant en zet het op de server.

antwoordde op 22/09/2008 om 06:43
bron van user

stemmen
0

Een voorbeeld van een bruikbare opgeslagen procedure Onlangs schreef ik in een externe taal die niet mogelijk in PL / SQL zou zijn geweest is een versie van 'df' waardoor SQL tafel generatoren om een ​​tablespace halen met de meeste vrije ruimte beschikbaar is tijdens de uitvoering.

Ik gebruikte plperlu, en het was relatief eenvoudig, hoewel ik moest voorzichtig met data typen te zijn.

antwoordde op 24/07/2012 om 16:20
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more