rdbms-agnostic

Just found out that Oracle does not like it when you use the AS keyword to alias a subquery: SELECT * FROM (SELECT * FROM products) AS p I need to keep my SQL queries as portable as possible. Will the removal of the AS keyword in the above query affect any other RDBMS? Jorge Campos The pattern for the SQL 99 ANSI is that the table can have an alias WITHOUT the AS keyword so, you can take out AS and it should work on every RDBMS. See it on fiddle: MySQL Oracle PostgreSql SQLLite SQLServer In ISO/IEC 9075-2:1999 , section 7.6 <table reference> , page 232: <table reference> ::= <table primary> |

Sorry for the ignorant question, but what kind of applications wouldn't require an ACID compliant database server? I have a SQL Server background where ACID has always "been there", and now researching other DBMSs has me thinking. Most every application I can think of would desire either atomicity or isolation. Thanks! Anything based on a NoSQL-type database is sacrificing ACID compliance in exchange for something, usually speed. Twitter, Facebook, Reddit, Digg, etc... all are partially non-acid based It's a paradox that every RDBMS guy thinks the sky would fall without ACID, but most NoSQL

You often see database fields set to have a magnitude of 255 characters, what is the traditional / historic reason why? I assume it's something to do with paging / memory limits, and performance but the distinction between 255 and 256 has always confused me. varchar(255) Considering this is a capacity or magnitude, not an indexer , why is 255 preferred over 256? Is a byte reserved for some purpose (terminator or null or something)? Presumably varchar(0) is a nonsense (has zero capacity)? In which case 2^8 of space should be 256 surely? Are there other magnitudes that provide performance

In MSSQL 2005 I just struck the infamous error message: Introducing FOREIGN KEY constraint XXX on table YYY may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. Now, StackOverflow has several topics about this error message, so I've already got the solution (in my case I'll have to use triggers), but I'm curious as to why there is such a problem at all. As I understand it, there are basically two scenarios that they want to avoid - a cycle and multiple paths. A cycle would be where two tables have cascading

I'm just trying to get a general idea of what views are used for in RDBMSes. That is to say, I know what a view is and how to make one. I also know what I've used them for in the past. But I want to make sure I have a thorough understanding of what a view is useful for and what a view shouldn't be useful for. More specifically: What is a view useful for? Are there any situations in which it is tempting to use a view when you shouldn't use one? Why would you use a view in lieu of something like a table-valued function or vice versa? Are there any circumstances that a view might be useful that