Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I've been asked to support and take on a PostgreSQL app, but am a MySQL guy - is this a realistic task?
PostgreSQL has some nice features like generate_series, custom aggregate functions, arrays etc, which can ease your life greatly if you take some time to learn them.
On the other hand it lacks some features of MySQL like using and assigning session variables in queries, FORCE INDEX, etc., which is quite annoying if you are used to these features.
If you just use basic SQL, then you will hardly notice any difference.
How different is PostgreSQL to MySQL?
That depends if you're talking about SQL only (which is mostly the same) or the stored procedures (which are quite different).
is this a realistic task?
Absolutely. PostgreSQL has very good documentation and community. There are also lot of ppl, who have experience with MySQL and PostgreSQL.
"MySQL vs PostgreSQL wiki" — centers on "which is better", but gives you some idea of differences.
PostgreSQL compared to MySQL is as any other pair of DBMSs compared. What they have in common is non-functional, specifically the consequences of each being open source. In terms of features, use, and strengths they are no closer to each other than PostgreSQL is to Oracle or DB2 is to Sybase.
Now on to your real question: you are a SQL guy, albeit one who has not yet had experience with PostgreSQL. This is a completely realistic task for you, and a good one since you'll expand your understanding of the varieties of DBMSs and gain a perspective on MySQL that you can't get from working solely within its sphere.
As someone who was once in exactly the same position, my guess is that you'll quickly pick up PostgreSQL and might even hesitate to return to MySQL ;-).
If you're interested in the different flavors of SQL, here are a few resources (though some may be outdated):
SQLZoo
SQL Dialects Reference Wikibook
Tips on Writing Portable SQL
SQL Bible
You may want to take a look at these pages:
Why PostgreSQL Instead of MySQL: Comparing Reliability and Speed in 2007, Why PostgreSQL Instead of MySQL 2009.
I faced the same situation about a month ago.... I have been doing fine with postgres. There is a strong online community for postgres and you should be able to find help if you run into any trouble and learn stuff easily :)
I didn't take very long to switch from MySQL to PostgreSQL back when I first started using PostgreSQL in anger at a previous company. I found it very nice and very refreshing (not that MySQL was bad) compared to MySQL which I had used previously. PostgreSQL was also a good stepping stone to Oracle which I use at my current company. I liked that it had a proper command line application like MySQL, but the configuration options are harder - but if you're not setting it up then there is no problem.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I remember reading somewhere that SQLite follows the standard completely, when possible (as in, switching databases, etc. is not implemented, as well as using dynamic types). One would expect that the other flavors would also follow the standard, and then tack on some extra features.
Are these expectations correct? If so, I would expect that (almost) any valid SQLite code would also be valid PostgreSQL, MySQL, or other SQL flavors as well.
Is this true? Or,
TL;Dr is there any valid SQLite that doesn't use its file-based nature, that isn't valid in other dialects?
I'm not sure if this is the answer you are looking for, but.
SQLite -- as with every database -- varies from the standard. There are lots of things in SQLite that don't work in other databases. This is highly database-pair centric. But here are some examples:
limit doesn't work in SQL Server or Oracle.
instr() doesn't work in SQL Server.
printf() doesn't work in any other database as far as I know.
Nor does likely(), unlikely(), randomblob(), total_changes(), zeroblob(), like(), glob().
min() and max() with multiple arguments do not work in any other database, as far as I know.
len() doesn't work in Oracle or Postgres.
soundex() doesn't work in Postgres.
substr() doesn't work in SQL Server.
trim() doesn't work in SQL Server.
ltrim() and rtrim() don't work in Postgres.
I decided to stop at 10 (and I apologize for any errors in the above). There are many more examples.
Code written in SQLite -- or in any database -- simply is not guaranteed to work in any other database, with the exception of closely related database pairs, such as MySQL/MariaDB, SQL Server/Sybase (and they have diverged a lot), and Postgres and a bunch of Postgres-derived databases.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
My question is more for practice than a debug issue.
At work, we use a Java-JEE/Oracle solution and the least I can say is we need to perform SQL query, anticipate SQL performances, handle SQL issues like foreign key or orphan line and so on.
So from my point of view, doing SQL is very important. For a new project, we are looking to implement the solution in Ruby on Rails. But most of the tutorial and code I see, seems to nest every Postgres SQL code under Active Record implementation. I have already experienced some similar issue with the Java Hibernate framework and its "no need SQL code." Some production issues were madness, the generated hidden SQL query were not easy to read and there is no deal with index or foreign key.
Any one can tell me what risk we have to use only Active Record ?
What is the proper process to avoid most common Ruby/SQL interface issues ?
When did you need to open your SQL console et type some SQL query ?
Share a little bit its experience on these points.
If you have any relevant link dealing with this topic.
Thank you very much !
You can still use sql.
Either low level, where you receive an array of arrays of values.
Or a little more high level, so you receive objects, with methods like find_by_sql.
Or by providing only sql-fragments, for example for the where-clause.
How often you need sql depends on your use case.
Ruby is about objects, sql is about tables. ActiveRecord handles objects as rows in a table. That works most of the time quite good. All simple queries are handles automatically. You can describe relations between objects, and even joins to retrieve these relations are handled.
For queries with several joins or group_by, it is sometimes easier to write the sql instead of instructing activerecord to build the sql you have in mind.
Also you need to have an eye on what sql is generated, as it is easy to write code that is inefficient, for example by generating many small sql statements.
The official Rails guides about "models" are the most important resource. From sql perspective you should have a look at "Active Record Query Interface"
http://guides.rubyonrails.org/active_record_querying.html
I also done a presentation about rails database optimisation, but it for rails 3.2 and a little out of date (joins are now better handled)
http://meier-online.com/en/2012/08/presentation-rails-database/
I'm on a project where I was asked to take a quick peek at some reporting SQL (in a SQL Server 2K5 environment) and was surprised at what I found: 4 to 5 levels of subquerys, distinct clauses, unions, and NoLock hints (which were needed because the SQL was running so long it was blocking standard processing) - all in the same set!.
Because I (foolishly :) mentioned that I thought the SQL was inefficient I've been labeled the "expert" and have been tasked with creating a test for a couple of interviewees to do that will assess their SQL optimizing abilities. I'm hoping someone can point me to some URLS, or maybe provide a list that I can use to help weed out the good from the bad.
Since you mentioned the SQL Server 2005 environment:
More SQL Server interview questions than you possibly could have imagined:
The classic set. Most interviewees will probably have studied these...maybe a good way to gauge who has prepared.
Another classic
Questions from one of the original Stack Overflow DBAs
Another link for best SQL questions and answers
I would give them a Query plan (via EXPLAIN, or whatever your flavor of SQL uses as a keyword) and see if they can decipher what it means, what the weak points are, and how to improve the query.
Look at MySQL's Explain Documentation for help using MySQL's explain and what it means.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
There was this old sql server tool called Lectoneth or something like that, you'd put sql queries in it, and it would rewrite it for you.
I think quest bought them out, but I can't find where to download a free copy of that software.
Really helps when you have no dba, and have lots of sql queries to rewrite.
Thanks
Craig
Doesn't ring a bell, and presumably you've seen, but nothing obvious on Quest's website
Perhaps a tool like Red Gate's SQL Prompt would help - the Pro edition does SQL reformatting.
Edit
Think i've found what you're looking for, mentioned here - LECCO SQL Expert. The link to the Lecco website does indeed direct to quest, but a 404.
LECCO SQL Expert is the only complete
SQL performance tuning and
optimization solution offering
problematic SQL detection and
automatic SQL rewrite. With its
built-in Artificial Intelligence (AI)
based Feedback Searching Engine, LECCO
SQL Expert reduces the effort required
to optimize SQL and makes even the
most junior programmer an expert.
Developers use LECCO SQL Expert to
optimize SQL during application
development. DBAs eliminate
problematic SQL before users
experience application performance
problems by using LECCO SQL Expert in
production systems.
Looks like it's no longer about - all mentions of I could find indicated it supported up to SQL 2000, and stale links - looks like it wasn't a free tool. As said in my comments, I think this kind of thing is a skill well worth possessing and would benefit in the long run to not relay on a tool to try and do it for you.
I wasn't aware of this tool before now, so I have picked up something from this question - got me intrigued!
Final Update:
To confirm, that product has indeed gone as Lecco was acquired some years ago now. Thanks to Brent Ozar for confirmation.
I think you're looking for a product that's been merged into Toad for SQL Server. The commercial version of Toad has a SQL Optimizer feature that tries lots of ways to rewrite your SQL statements, then tests them to find which ways are the fastest.
You can download Toad here:
http://www.toadsoft.com/
But be aware that that feature is a paid-version-only feature.
Well rather than spending your time looking for a magic bullet, why not spend some time learning performance tuning (you will need a book, this is too complex for the Internet generally). Plus it is my belief that if you want ot write decent new code, you need to understand performance in databases. There is no reason to be unable to write code that avvoids the most common problems.
First, rewrite every query to use ANSII syntax anytime you open it up to revise it for any other reason. Code review all SQl changes and do not pass the code review unless explicit joins were used.
Your first step in performance tuning to identify which queries and procs are causing the trouble. You can use tools that will tell you the worst performing queries in terms of overall time, but don't forget to tune the queries that are run frequnetly as well. Cutting seconds off a query that runs thousands of times a day can really speed things up. Also since you are in oprod already, likely your users are complaining about certain areas, those areas should be looked at first.
Things to look for that cause performance problems:
Cursors
Correlated subqueries
Views that call views
Lack of proper indexing
Functions (especially scalar function that make the query run row by row insted of through a set)
Where clauses that aren't sargeable
EAV tables
Returning more data than you need (If you have anything with select * and a join, immediately fix that.)
Reusing sps that act on one record to loop throuhg a large group of records
Badly designed autogenerated complex queries from ORMs
Incorrect data types resulting in the need to be continually be converting data in order to use it.
Since you have the old style syntax it is highly likely you have a lot of accidental cross joins
Use of distinct when it can be replaced with a derived table instead
Use of union when Union all would work
Bad table design that requires difficult construction of queries that can never perform well. If you find yourself frequently joining to the same table multiple times to get the data you need, then look at the design of the tables.
Also since you have used implicit joins you need to be aware that even in SQL Server 2000 the left and right implicit syntax does not work correctly. Sometimes this interprets as a cross join instead of a left join or right join. I would make it a priority to find and fix all of these queries immediately as they may currently be returning an incorrect result set. Bad data results are even worse that slow data returns.
Good luck.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Are User Defined Data Types in SQL Server something that a intermediate SQL user should know and use?
What are pros and cons of using UDTs?
Never use them is my advice. You are in a world of hurt if you ever have to change the definition. Perhaps this has improved since SQL Server 2000 and someone with more familiarity with the newer versions can tell you whether it is now safe to get in the water, but until I had confirmation of this and had checked it out myself with a test, I wouldn't put it on my production system.
Check out this question for details:
How to change the base type of a UDT in Sql Server 2005?
I do not use code-based UDTs because I don't think that the extra complexity warrants the advantages. I do use T-SQL UDTs because there's very little extra complexity so that the advantages are worth the effort. (Thanks go to Marc_s for pointing out that my original post was incomplete!)
Regarding Code-based UDTs
Think of it this way: if your project has a managed code component (your app) and a database component (SQL Server) what real advantage do you gain from defining managed code in the database? In my experience? None.
Deployment is more difficult because you'll have to add assemblies to your DB deployment and alter these assemblies, add files, etc. within SQL Server. You'll also have to turn on the CLR in SQL Server (not a big deal but no one's proven to me that this won't have a performance/memory penalty). In the end, you'll have exactly what you would have had if you had simply designed this into your application's code. There may be some performance enhancement but it really strikes me as a case of premature optimization - especially since I don't know if the overall performance suffers due to having the CLR on versus off.
Note: I'm assuming that you would be using SQL Server's CLR to define your types. HLGEM talks about SQL Server 2000 but I'm not familiar with 2000 and thought it only had UDFs and not UDTs in externally-defined dlls (but don't quote me...I really am not familiar with it!).
Regarding T-SQL UDTs
T_SQL UDTs can be defined in SQL alone (go to "Programmability | Types | User-defined Data Types" in SQL Server Management Studio). For standard UDTs I would in fact recommend that you master them. They are quite easy and can make your DDL more self-documenting and can enforce integrity constraints. For example, I define a "GenderType" (char(1), not nullable, holding "M" or "F") that ensures that only appropriate data is permitted in the Gender field.
UDTs are pretty easy overall but this article gives a pretty good example of how to take it to the next level by defining a Rule to constrain the data permitted in your UDT.
When I originally answered this question I was fixed on the idea of complex, code-defined types (smacks palm to forehead). So...thanks Marc.
The pro of user defined types is addressed quite well by Alex Papadimoulis. The cons have been well stated here.
I would also like to point out that the sp_bindrule function has been deprecated, as noted by Alex's post. I'm not sure when it was deprecated but it is now. In fact, rules are deprecated as a whole.
Were I to want to create a type with a restriction, I'd consider using a user defined table type with a check constraint on the appropriate column(s). This also gives me a way of building a complex data type.
I can't really recommend the use of any sql-implementation specific features that make it harder when you are growing out of mssql and are migrating to another dbms. For our dwh dbs we started on mssql, migrated to oracle and have since last year graduated to hp vertica.