Eli kun ohjelmistofirma edellyttää mysli-osaamista, niin jos jossain vaiheessa tietokantaa lähdetään rakentamaan ihan tyhjästä, kertokaa kokeneemmat, väännetäänkö siellä työpaikalla ihan tekstieditorilla sql-tiedostoa putkeen, vai hyödynnetäänkö joitain ehkä jopa graafisia työkaluja?
Itselläni oli IT-tradenomi-opinnoissa tietokantojen suunnittelukurssi, ja käytimme PostReSQL:ää ja MongoDB:tä, ja ajettavat .sql-komennot valmistettiin ajamalla RISE-Editorissa graafisen työkalun käytön jälkeen relaatiokanta kantapalvelimelle. Onko tämä tätä päivää ohjelmistoyrityksissä?
Itselläni oli IT-tradenomi-opinnoissa tietokantojen suunnittelukurssi, ja käytimme PostReSQL:ää ja MongoDB:tä, ja ajettavat .sql-komennot valmistettiin ajamalla RISE-Editorissa graafisen työkalun käytön jälkeen relaatiokanta kantapalvelimelle. Onko tämä tätä päivää ohjelmistoyrityksissä?
Vastaukset 7
Vanhimmat
Molempia tapoja olen käyttänyt eri yrityksissä.
Ja jos ei työpaikka osta välinettä niin olen source versioita löytyy. Esim DBeaver ja Toad
Kyllä vi tai notepad ovat ihan ok SQL-skriptien vääntämiseen jos sattuu osaamaan. Tokihan kaikki graafiset hilavitkuttimet paikkaavat puutteellista osaamista mukavasti. Osaavalle nopein tapa lienee tekstieditori.
Yleensä+kanta+suunnitellaan+etukäteen+peruskuntoon,+mutta+"isommat"+kannat+ovat+melko+varmasti+pitkäaikaisen+kehittymisen+tulosta.+Eli+ei+ole+heti+kärkeen+tehty+100+taulua+ja+niissä+yhteensä+4000+kolumnia.+Todennäköisesti+ihan+ekassa+versiossa+oli+5+-+10+taulua+ja+ehkä+50+-+100+kolumnia.+Sitten+vuosien+myötä+se+on+siitä+kasvanut.
Itse+olen+lähinnä+nähnyt+ORM-tyyliä,+jossa+siis+kantarakenne+tehdään+koodilla,+eikä+SQL-lauseilla.+Eli+esim.+Pythonissa+SQLAlchemyllä+näin:
class+User(db.BaseModel):
__tablename__+=+"user"
id+=+db.Column(db.Int,+primary_key=True)
username+=+db.Column(db.String(100),+nullable=False)
email+=+db.Column(db.String(255))
Se+sitten+generoidaan+automaattisesti+varsinaiseen+kantaan+tähän+tyyliin,+komentorivillä+tai+vaikkapa+Ansible+playbookissa:
python+manage.py+db+upgrade
Sitten+jos+haluaa+lukea+arvoja+kannasta:
#+Jos+on+tiedostossa+apps/user/model.py
from+apps.user.model+import+User
gmail_users+=+User.query.filter(User.email.like("%@gmail.com")).all()
for+user+in+gmail_users:
print("Email-osoite+on:+{}".format(user.email))
Tuo+tulostaisi+kaikki+kannasta+löytyneet+tulokset+tuolle+haulle,+joka+vastaa+tätä:
SELECT+*+FROM+user+WHERE+email+LIKE+"%@gmail.com"
Hupsista, eli siis "db.Model" tuon "db.BaseModel" sijaan, ja "db.Integer" tuon "db.Int" sijaan.
http://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html
"ORM is a terrible anti-pattern that violates all principles of object-oriented programming, tearing objects apart and turning them into dumb and passive data bags. There is no excuse for ORM existence in any application, be it a small web app or an enterprise-size system with thousands of tables and CRUD manipulations on them. What is the alternative? SQL-speaking objects."
Tuo näyttää koskevan Javaa, joka on monelle jo itsessään antipattern :) Tuolla sivulla oleva "oikein tehtynä näin" -esimerkki on muuten juuri samanlainen kuin esim. SQLAlchemyn toteutus.