rdbms-agnostic | 易学教程

SQL portability gotchas

阅读更多关于 SQL portability gotchas

问题 My company has me working on finishing a back end for Oracle for a Python ORM. I'm amazed at how much differently RDBMSes do things even for the simple stuff. I've learned a lot about the differences between Oracle and other RDBMSes. Just out of sheer curiosity, I'd like to learn more. What are some common "gotchas" in terms of porting SQL from one platform to another? Please, only one gotcha per answer. 回答1: Oracle does not seem to have a problem with cursors, they are a huge performance

SQL portability gotchas

阅读更多关于 SQL portability gotchas

What are the disadvantages of having many indices?

阅读更多关于 What are the disadvantages of having many indices?

问题 I recently sped up a complicated query by an order of magnitude by giving SQLite a good index to work with. Results like this make me wonder if I should index a lot of other fields that are commonly used for JOINs or ORDER BY clauses. But I don't want to get overzealous and have it backfire on me: I assume there must be some reasons not to create indices, or every field would be indexed by default. I'm using SQLite in this case, but of course DBMS-agnostic advice is welcome as well. 回答1:

SQL design for survey with answers of different data types

阅读更多关于 SQL design for survey with answers of different data types

问题 I am working on an online survey. Most questions have a scale of 1-5 for an answer. If we need to add a question to the survey, I use a simple web form, which does an INSERT into the appropriate table, and voila! surveys are asking the new question -- no new code or change to the database structure. We are being asked to add survey questions that can have answers of different data types. The spec is to have the survey 'configurable', so that at any point in the future, when someone says, "We

Why historically do people use 255 not 256 for database field magnitudes?

阅读更多关于 Why historically do people use 255 not 256 for database field magnitudes?

问题 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

What are views good for?

阅读更多关于 What are views good for?

问题 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

Do you use the OUTER keyword when writing left/right JOINs in SQL?

阅读更多关于 Do you use the OUTER keyword when writing left/right JOINs in SQL?

问题 I often see people who write SQL like this: SELECT * from TableA LEFT OUTER JOIN TableB ON (ID1=I2) I myself write simply: SELECT * from TableA LEFT JOIN TableB ON (ID1=I2) To me the "OUTER" keyword is like line noise - it adds no additional information, just clutters the SQL. It's even optional in most RDBMS that I know. So... why do people still write it? Is it a habit? Portability? (Are your SQL's really portable anyway?) Something else that I'm not aware of? 回答1: OUTER really is

Do you use the OUTER keyword when writing left/right JOINs in SQL?

阅读更多关于 Do you use the OUTER keyword when writing left/right JOINs in SQL?

I often see people who write SQL like this: SELECT * from TableA LEFT OUTER JOIN TableB ON (ID1=I2) I myself write simply: SELECT * from TableA LEFT JOIN TableB ON (ID1=I2) To me the "OUTER" keyword is like line noise - it adds no additional information, just clutters the SQL. It's even optional in most RDBMS that I know. So... why do people still write it? Is it a habit? Portability? (Are your SQL's really portable anyway?) Something else that I'm not aware of? OUTER really is superfluous, as you write, since all OUTER joins are either LEFT or RIGHT , and reciprocally all LEFT or RIGHT joins

SQL portability gotchas

阅读更多关于 SQL portability gotchas

My company has me working on finishing a back end for Oracle for a Python ORM. I'm amazed at how much differently RDBMSes do things even for the simple stuff. I've learned a lot about the differences between Oracle and other RDBMSes. Just out of sheer curiosity, I'd like to learn more. What are some common "gotchas" in terms of porting SQL from one platform to another? Please, only one gotcha per answer. Oracle does not seem to have a problem with cursors, they are a huge performance problem in SQL server. Actually pretty much all performance tuning is database specific (which is why ANSII

What are the disadvantages of having many indices?

阅读更多关于 What are the disadvantages of having many indices?

I recently sped up a complicated query by an order of magnitude by giving SQLite a good index to work with. Results like this make me wonder if I should index a lot of other fields that are commonly used for JOINs or ORDER BY clauses. But I don't want to get overzealous and have it backfire on me: I assume there must be some reasons not to create indices, or every field would be indexed by default. I'm using SQLite in this case, but of course DBMS-agnostic advice is welcome as well. Indexes slow down inserts and updates (which can become a really serious issue with locking) and cost disk space