The Database Programmer
database-programmer.blogspot.com · Personal blog · on HN since 2008
A blog on database design for application developers, covering table design, foreign keys, history tables, and business logic.
What HN saysCommenters recommend it for learning to use a database as a real database rather than a persistent hash table, though it says less about why.
17HN people shared it
3linked it in comments
26stories submitted
148story points
13 years agolast shared
2008people per year2026
Most-shared posts
- 1Minimize Code, Maximize Data2 people · 46 points · first shared 2008 · 12 comments on HN
- 2Maintaining One Code Base with Possibly Conflicting Custom Features2 people · 5 points · first shared 2011 · discussion on HN
- 3The Wonderful Awful Browser1 people · 26 points · first shared 2008 · 15 comments on HN
- 4The Database Programmer: Advanced Table Design: Secure Password Resets1 people · 15 points · first shared 2008 · 5 comments on HN
- 5A Working Definition of Business Logic, with Implications for CRUD Code1 people · 11 points · first shared 2010 · 3 comments on HN
- 6History Tables in a Database1 people · 9 points · first shared 2008 · discussion on HN
- 7The Database Programmer: Different Foreign Keys for Different Tables1 people · 5 points · first shared 2008 · 1 comments on HN
- 8Data and Code at the Application Level1 people · 4 points · first shared 2008 · discussion on HN
- 9Can You Really Create A Business Logic Layer?1 people · 3 points · first shared 2011 · discussion on HN
- 10Database Performance 1: Huge Inserts1 people · 3 points · first shared 2008 · discussion on HN
- 11Business Logic: From Working Definition to Rigorous Definition1 people · 2 points · first shared 2011 · discussion on HN
- 12The Database Programmer: The Data Dictionary and Calculations, Part 11 people · 2 points · first shared 2009 · discussion on HN
- 13The Database Programmer: Upgrading Indexes With a Data Dictionary1 people · 2 points · first shared 2009 · discussion on HN
- 14The Argument For Denormalization1 people · 2 points · first shared 2008 · discussion on HN
- 15All Software Development is Schema Management1 people · 2 points · first shared 2013 · discussion on HN
What HN people wrote when they linked it
papsosouid · 2013-06-19
Unfortunately, I don't know of anything. http://database-programmer.blogspot.ca/ is good for learning about how to use a database as a database instead of a persistent hash table, but it doesn't really address the why of it so much.
sjwright · 2013-10-10
Because you can't cleanly map objects to sets nor sets to objects. Sure, if you want to pretend an RDBMS is an object store you certainly can, but you'll be forced to have an incredibly stupid schema, and will miss out on much of the benefits of a good RDBMS.
Turning a powerful SQL database engine into an object storage emulator is just sad.
If your underlying data suits objects better than sets, consider using something that's designed for the job, like one of the many non-SQL database systems.
Although it may seem trite to say it, Object/Relational Mapping
is the Vietnam of Computer Science. It represents a quagmire which
starts well, gets more complicated as time passes, and before long
entraps its users in a commitment that has no clear demarcation
point, no clear win conditions, and no clear exit strategy.
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.…
Well worth reading.
Also:
http://database-programmer.blogspot.com.au/2010/12/historical-perspect…
http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-…