|
All,
Just chiming in . . . we’ve taken a somewhat different approach and actually encourage our programmers to build out thier own DBs. We’re using Postgres to aggregate many varied datasources into postgres as a cahing system, and then develop against
this aggregated data. Yes, we understand that the realtime stuff is a laggy process. The intent here is to give the programmers a background in DB operation and performance expectations, especially since we primarilry build for Web Use.
bobb
On
Sun, 8 Apr 2018 14:39:49 -0700
Guyren
Howe <guyren@xxxxxxxxx>
wrote:
I am a Rails developer at a medium-large size company. I’ve mostly
worked at smaller companies. I’ve some exposure to other web
development communities.
When it comes to databases, I have universally encountered the
attitude that one should treat the database as a dumb data bucket.
There is a *very* strong aversion to putting much of any business
logic in the database. I encounter substantial aversion to have
multiple applications access one database, or even the reverse: all
abstraction should be at the application layer.
My best theory is that these communities developed at a time when
Windows was more dominant, and just generally it was *significantly*
easier to use MySQL than Postgres for many, particularly new,
developers. And it is pretty reasonable to adopt an aversion to
sophisticated use of the database in that case.
The
biggest single problem in most cases is a combination
of
communiction and attitude.
Recall
that most programmers are not DBA's and don't have access to
create
anything in the database. Traditionally the High Priests of
Holy
Data don't allow mere peons to create or modify content in the
databases.
Result is that programmers *have* to do most of their
logic
in code, even if the results put hugely more load on the servers.
The
DBA's are also not Well Qualified Genious Programmers who obviously
know
much more than mere DBA's about what the real use of data is
supposed
to be. They don't need no stinkin' SQL! They have the magic
of
ORM!
Net
result: People talk past one another.
I've
nearly been lynched for creating ten-row temporary tables without
prior
written permission or even suggesting that we might add indexes
to
support more effecient use of views.
I've
also nearly strung programmers up for running hundreds of
"select
* from table" statements because they weren't willing to
figure
out how to write a join or simple filter or give me enough
data
to do it for them.
Good
example are ORM packages: Most of really hideous code required
for
joins, group by, coalesce can easily be pushed into views allowing
simple
select X from Y where or one-line joins. DBA's can craft views
that
make sense, programmers could use them to simplify their code.
Q:
When is the last place you worked where DBAs were pigs (vs.
chickens)?
Q:
How often was a DBA involved in the analysis and design of cycle
of
reporting?
Q:
How many programming projects have you been on where the hackers
were
willing to write clear, concise data reqirements and keep
them
up to date?
When
that happens people will use the databases as tools, ORM code
will
be [semi-] maintainable, and we'll live happily for ever after.
--
Steven
Lembark 1505 National Ave
Workhorse
Computing Rockford, IL 61103
lembark@xxxxxxxxxxx +1
888 359 3508
"The true measure of a man is how he treats someone who can do him absolutely no good." - Samuel Johnson
|
