Yes, that's looking steadily better the more I think about it. Instead
of a single CRUD GUI program I've got two, the idea being that one can
be given to anybody because it can't damage the database (no
insert/update/ delete capability at all while the other, which can do
these things, is intended only for suitable authorised users: most data
is bulk loaded and the update GUI is only there for removing to odd
piece of junk and tidying up.
I think relying on control over software distribution to maintain database
security is probably not the best idea. You probably know this, of course,
and for a lightweight, non-mission-critical app, controlling the software
might be enough.
If possible, though, i'd suggest creating two user accounts in the
database, one with full access, and one only with read rights, and
controlling the distribution of the passwords. In fact, i'd create three -
a full-access account for the DBA, an account with the ability to edit the
data, but not do DDL, for the update app, and a read-only one for the
search app. Or an account for each actual user, but that becomes more of a
headache to manage - but perhaps necessary.
IOW, a single model for these GUIs isn't a bad idea.
That i agree with.
I have almost no OO background and have no idea who the currently
recognised OO design gurus are.
Fair enough.
I've heard of Booch, but have never seen him mentioned here. Hence the
question.
I think he's one of the ones with good facial hair. Ah yes:
http://yuiblog.com/assets/booch.jpg
Booch was one of the top chiefs in the early-mid '90s wave of OO design
thinking. That era was dominated by big ideas - big processes (Rational,
Booch, OMT), big notations (UML), big books, big words. People thought
that big, complex problems had to be solved with correspondingly big and
complex tools of various kinds.
I would say that subsequent history has shown this to be mistaken: what's
worked has typically been more focused, more about getting foundational
things right, running before we can walk. Design patterns are about this -
getting the structure of code right at the level of classes and clusters
of classes, not whole architectures. Unit testing is all about this -
writing and enforcing specifications at the level of methods and classes.
Drawing diagrams with boxes and arrows (and using much of the UML
notation), but not making drawing diagrams an activity in itself.
Rumbaugh and Jacobson are other big names from this period. They're all
very smart guys, and i don't for a second mean to downplay the importance
of their work: that huge burst of talking and writing was the birth of
serious thinking about OO design, and we could no more have reached the
stage we're at now (which i have to say is by no means a mature stage -
it's still mostly guesswork) without it than classical music could have
happened without the baroque (or, perhaps, than we could have developed
bronze tools without what we'd learned from flint).
Thanks. Thats exactly what I wanted to know.
BTW, and to show where I'm coming from, apart from K&R, I think the best
non-OO programming books in my library are:
1) Software Tools in Pascal (Kernighan & Plauger)
2) Algorithms (Sedgewick)
I love that book! My first (and only, really) algorithms book. It has a
few warts, but i learned a lot from it. Patricia trees, in particularly,
are something that have stayed with me. His stuff on sorting is excellent
on the basics, but i would have loved to have read about the things that
come after quicksort and mergesort (although maybe those were only
developed after the book was published, now i come to think of it).
3) The Practise of Programming (Kernighan & Pike)
4) Algorithms + Data Structures = Programs (Wirth)
5) An Introduction to Database Systems (Date)
Also a classic. Rigorous but lucid. I had the sixth edition.
and, no, I don't have a copy of Knuth. So far Sedgewick and Wirth have
filled that need.
I can imagine. Knuth is to algorithms books what the Oxford English is to
Dictionaries: definitive, scholarly, and endlessly fascinating, but a bit
heavy to be a practical handbook.
(1) is still about the best book I know about designing reusability into
code modules while (3) should be read by every programming neophyte, OO
or non-OO for its advice in code readability and designing testability
into your code.
I don't know them. They both sound interesting, though - i'll see if i can
find a copy of the K&P in particular.
As for (5), Date is great. He manages to combine an understanding of DB
principles with good design and implementation guidance.
Should be compulsory reading!
tom
