• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Programowanie obiektowe a sQL

Aruba Cloud VPS - 50% taniej przez 3 miesiące!
0 głosów
230 wizyt
pytanie zadane 25 października w SQL, bazy danych przez sisOOO Obywatel (1,430 p.)
edycja 25 października przez sisOOO
Witam

mam taki problem, z którym nie mogę sobie poradzić, nie dotyczy on stricte programowania, czy zaptań jeżeli chodzi o SQL'a raczej to problem typu "Po co?"

Dajmy dla przykłady SQLite i Pythona (ale to może być wszystko inne - MySQL, Postgre etc Java, C# czy każdy język, który ma paradygmat obiektowości).

No i tutaj pytanie, po co obiektowość, skoro sam rekord w bazie można potraktować jako obiekt w tym przypadku. Dla przykładu
Mamy table id, imie, nazwisko, mail
To po co jeszcze tworzyć to samo z poziomu kodu? No i co potem wsadzać do bazy danych? self.imie, self.nazwisko i self.mail? Jakby nie potrafię zrozumieć tego po co coś takiego robić?

Czy może obiektowość tego typu powinna wyglądać w następujący sposób:
Tworzymy klasę User/Uzytkownik
Następnie w initcie wsadzamy naszą bazę danych - chodzi o te wszystkie connection, cursor oraz metody które daliśmy dla klasy baza danych.
No i wreszcie robimy metody, które będą odzwierciedlać użytkownika czyli dodaj_uzytkownika(self, imie, nawisko, mail). I wtedy używając naszej self.db wykonujemy execute z Insertem do db?

Czy dobrze to rozumiem? Czy może jednak jest coś jeszcze co warto na początku przygód z obiektowością przy bazach danych wiedzieć?

Z góry dzięki :)

1 odpowiedź

+3 głosów
odpowiedź 26 października przez marcin99b Szeryf (83,530 p.)
Jeśli nic nie robisz po drodze z tymi danymi w kodzie, to rzeczywiście kod jest bez sensu, można wystawić do używania samą bazę. Zazwyczaj jednak coś z nimi robisz, w jakiś sposób je przetwarzasz, weryfikujesz, podejmujesz decyzje w oparciu o nie, komunikujesz się z innymi aplikacjami w oparciu o te dane.

Dużo rzeczy można zrobić z poziomu samego SQL, kiedyś się tak robiło, ale SQL nie jest zbyt czytelny ani nie pozwala na bardzo dużo, nie ma do niego wielu bibliotek itd. Zazwyczaj aplikacje oparte głównie na SQL sprawiały dużo problemów przy większej skali. Później była moda na pisanie jak najmniej SQL samemu, najlepiej wcale i używanie ORM do wszystkiego co możliwe. Osobiście po latach obserwowania różnych podejść, uważam że najlepiej jest to odpowiednio zbalansować, mieć procedury SQL które wykonują proste akcje wokół bazy danych, poza prymitywną edycją danych potrafią wykonać proste operacje, typu podstawowa weryfikacja spójności albo podstawowa normalizacja

A obiektowość to po prostu jeden z sposobów wyobrażenia sobie jak działa projekt i masz mechanizmy w językach które ułatwiają pisanie kodu żeby wyglądał "jak w twojej wyobraźni", nic więcej. Takich sposobów jest sporo, jest podejście strukturalne, obiektowe, funkcyjne, proceduralne itd.

Kiedyś była moda na obiektowość i dużo książek z tamtego okresu wprowadza narracje że to najlepsze co udało nam się wymyślić, w ostatnich latach dużo ludzi widzi, że fascynacja obiektowością często powoduje mnóstwo problemów, lepsze jest podejście funkcyjne bo zmusza programiste do unikania wielu problemów... ale to też tylko obecna moda, za 5-10 lat będziemy na to narzekać i będziemy zachwycać się czymś innym.
komentarz 26 października przez sisOOO Obywatel (1,430 p.)
Haha racja, widzę właśnie tę narrację nastawioną na obiektowość i sam też widzę przyjemność z funkcyjnego programowania, jednak chcę poznać możliwość każdego paradygmatu :)

W ogóle za tak obszerną odpowiedź :)
komentarz 3 listopada przez reaktywny Nałogowiec (44,410 p.)

@marcin99b,

Takich sposobów jest sporo, jest podejście strukturalne, obiektowe, funkcyjne, proceduralne itd.

Strukturalne to jakie? Podasz przykłady?

komentarz 3 listopada przez reaktywny Nałogowiec (44,410 p.)

Marcin dobrze opisałeś problem. Programowanie funkcyjne jest super, przykładowo taki ELM na froncie sprawia, ze niemal unikamy błędów w kodzie finalnym. Elixir też jest ciekawym językiem, a szczególnie jego ekosystem.

Co do:

ale to też tylko obecna moda, za 5-10 lat będziemy na to narzekać i będziemy zachwycać się czymś innym

za 10 lat może AI zastąpić kompletnie programistów, AI tak zapierdziela....

 

komentarz 3 listopada przez marcin99b Szeryf (83,530 p.)

@reaktywny, Takie dość prymitywne które jest w prawie każdym współczesnym języku - takie oparte na ifach, pętlach, blokach kodu itp

Praktycznie każdy popularny język jest u swoich podstaw strukturalny, nie da się napisać zbyt dużo kodu bez używania elementów programowania strukturalnego... ale zamiast używania go jako samej podstawy, można pisać kod w większości ograniczony do tych podstaw - w sql i cobolu często się ogranicza do tych podstaw

Tak samo nie da się napisać pełnoprawnej aplikacji bez używania funkcji, a korzystanie z nich nie sprawia że nagle piszemy kod z podejściem "funkcyjnym"

komentarz 3 listopada przez reaktywny Nałogowiec (44,410 p.)
Wiem czym są języki funkcyjne czy paradygmat funkcyjny, bowiem jeden język może wspierać ich kilka (jak np. Python). Nie spotkałem się z językiem strukturalnym, tylko paradygmatem strukturalnym.

Tu jest to nieźle opisane:

https://boringowl.io/blog/czym-jest-programowanie-strukturalne
komentarz 3 listopada przez marcin99b Szeryf (83,530 p.)
Też sie nie spotkałem z językiem strukturalnym i nigdzie nie napisałem że takie są, tak samo nie spotkałem się z obiektowym ani funkcyjnym, bo każdy pełnoprawny język zawiera kilka paradygmatów

Ale pisząc kod któryś z nich jest dominujący w konkretnym projekcie.

Często twórcy języków preferują określony paradygmat i projektując język, troche sugerują którego chcieliby żeby ludzie używali, ale jeszcze nie spotkałem się z wymuszaniem któregoś
komentarz 3 listopada przez reaktywny Nałogowiec (44,410 p.)

Mogę się mylić ale Elixir, ELM, Scala, F#, OCaml czy Haskell wspierają (chyba) tylko paradygmat funkcyjny. Co do Elixir jestem pewien, natomiast reszty nie znam za bardzo.

Pomijając oczywiście podejście strukturalne, bo to wykorzystuje chyba każdy język,

komentarz 4 listopada przez marcin99b Szeryf (83,530 p.)
Z elixirem, scalą, ocamlem i f# to na pewno się mylisz, bo na pewno mają mieszane paradygmaty. Twórcy projektowali je myśląc o programowaniu funkcyjnym, ale wrzucili też inne rzeczy, żeby te języki były bardziej uniwersalne.

Kiedyś interesowałem sie paradygmatami i podobno haskell jest najbardziej "czysty rasowo" w kontekście funkcyjności, czyli ma najmniej zapożyczeń z innych paradygmatów.

Nie pamiętam czy jest 100% funkcyjny, dawno o tym czytałem, chyba nie 100% tylko najbliżej 100% (wśród popularnych języków)

Podobne pytania

0 głosów
2 odpowiedzi 546 wizyt
pytanie zadane 22 stycznia 2019 w PHP przez niezalogowany
0 głosów
1 odpowiedź 2,776 wizyt
pytanie zadane 14 sierpnia 2017 w Java przez Patryk Kirszenstein Bywalec (2,400 p.)
0 głosów
3 odpowiedzi 581 wizyt

93,159 zapytań

142,171 odpowiedzi

321,891 komentarzy

62,489 pasjonatów

Advent of Code 2024

Top 15 użytkowników

  1. 453p. - Marcin Putra
  2. 453p. - dia-Chann
  3. 447p. - Łukasz Piwowar
  4. 443p. - CC PL
  5. 431p. - Łukasz Eckert
  6. 428p. - rafalszastok
  7. 423p. - Adrian Wieprzkowicz
  8. 418p. - rucin93
  9. 410p. - Piotr Aleksandrowicz
  10. 408p. - ksalekk
  11. 402p. - Mariusz Fornal
  12. 340p. - ssynowiec
  13. 329p. - nidomika
  14. 319p. - Michal Drewniak
  15. 298p. - Dawid128
Szczegóły i pełne wyniki

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj

Wprowadzenie do ITsec, tom 1 Wprowadzenie do ITsec, tom 2

Można już zamawiać dwa tomy książek o ITsec pt. "Wprowadzenie do bezpieczeństwa IT" - mamy dla Was kod: pasja (użyjcie go w koszyku), dzięki któremu uzyskamy aż 15% zniżki! Dziękujemy ekipie Sekuraka za fajny rabat dla naszej Społeczności!

...