#39 in SQL books
Use arrows to jump to the previous/next product

Reddit mentions of A Guide to SQL Standard (4th Edition)

Sentiment score: 1
Reddit mentions: 2

We found 2 Reddit mentions of A Guide to SQL Standard (4th Edition). Here are the top ones.

A Guide to SQL Standard (4th Edition)
Buying options
View on Amazon.com
or
Specs:
Height9.5 Inches
Length6.75 Inches
Number of items1
Weight1.6975594174 Pounds
Width1 Inches

idea-bulb Interested in what Redditors like? Check out our Shuffle feature

Shuffle: random products popular on Reddit

Found 2 comments on A Guide to SQL Standard (4th Edition):

u/hga_another ยท 2 pointsr/KotakuInAction

> What they give you is pretty limited though... not nullable, foreign key references, uniqueness... What would be really more valuable is along the lines of the example I gave end of last comment, or restricting dates to be on a certain day of the week, or numbers to a certain range, etc etc.

Errr, there's the very generic CHECK constraint that lets you use Boolean expressions and I believe support everything you mention above out of the box (except for MySQL of course). Here's the PostgreSQL reference page on them, and here's an example of a constraint I used in my last project to make sure all the times stored in the database were in the same time zone:

ALTER TABLE time_slots
ADD CONSTRAINT time_slots_check_slot_time
CHECK (EXTRACT (TIMEZONE FROM slot_time) = '0')

You can do a lot more, as well as call stored procedures for calculations that are not built in. Of course, you have to write those procedures first :-)

> You mentioned something you did 94-96... which was right when I started high school. Think there is actually a bit of a generational gap on this LOL.

Yes, I do believe there is :-) I started programming in my junior year in high school, punched card FORTRAN "IV" on an IBM 1130 in 1978. Scare quotes because that dialect didn't have logical IF statements, each IF would GOTO another line, based on the result being negative, 0, or positive.... Trust me, except for the educational value, the aesthetics of handling card decks and feeding them into the card hopper etc., you didn't miss much. Sent me straight to the library to read up on software engineering.

> I don't really have an issue with using the constraints provided by an RDBMS... I just think they are woefully insufficient and that that logic should exist primarily in the main application code.

Here we should just agree to disagree, this is a fundamental and highly contested architectural issue, neither of us is "wrong", we each think a different choice is better.

> Another big part of that is I don't want an app too closely coupled to the choice of database, regardless of what it is.

That's not terribly hard to arrange, you've just got to have the self-discipline to use generic SQL, data types (or easily interchangeable ones, you've got all sorts of levels of isolation available), etc. I.e. I generally use this reference first, before getting database specific, and make note of the database specific features I use. Of course, I really try to limit the choices to solid MVCC ones, i.e. Oracle and PostgreSQL.

> (Although the comeback to that is of course SQLite).

Of course, although I've worked on a system that used the Sleepycat version of the Berkeley DB key/value database but didn't do much with that part of it, and as I mentioned before in less detail, incorporated a SQLite like single client object database called directly from C++ in a greenfield project I was the architect and primary developer of. I'm by no means dogmatic about this, I just have my preferences for complicated interrelated data.

Binary assets will depend on the database, I suppose, they've generally got a blob data type, but I've never used a RDBMS with blobs of any great size (4K or less if I remember correctly). Have never done geocoordinate data, did an interview for a job doing that, I know that's a specialty and would likely use a purpose built database for it, or I've heard PostgreSQL has an ... addon? that's supposed to be hot.

> But arguably the Mongo document model is better since read/write speed is much more paramount over making sure each and every metrics record was written OK.

"metrics record"? Note that except for perhaps one data warehouse application where I suppose loss of a few rows could have been tolerated (but that wouldn't come up except in ETL failure), it was imperative that the data was treated with ACID care.

u/mnemosyne-0002 ยท 1 pointr/KotakuInAction

Archives for the links in comments: