I work for a large organization that has an established and well populated MS-SQL server. However, I am not a Microsoft user, and my database of choice is MySQL. I am looking for a solution that will allow me to either...
-Directly query our MS-SQL server from my MySQL server
and/or
-Set up some sort of job that will copy data systematically from the MS-SQL server to our MySQL server.
It looks like Linked Servers may be part of the solution, however everything I have found describes scenarios where MS-SQL is accessing MySQL, not the other way around.
To be clear I want my MySQL server to talk to/query/pull data from my MS-SQL server.
Any help appreciated!
As far as I'm aware, you can't query any other RDBMS vendor from MySQL. MySQL's remote access feature is FEDERATED tables, which only work with other MySQL databases as far as I know.
About the simplest way you could do this would be to use SQL Server's Import/Export Wizard to create a simple package that copies the data to your MySQL server through an ODBC or ADO.NET connection to the MySQL database.
To be clear I want my MySQL server to talk to/query/pull
data from my MS-SQL server.
I think it is hard to even assume this is the best decision. Without a TON more context of what the real problem is and/or the real "need", answers vary widely from "just use ms-sql" to other levels of ad-hoc ETL. That said, some abstract feedback.
There is nothing wrong with MS-SQL, as long as you are (a) not paying for it and (b) have a clean solution to use it from a real POSIX based system. Technically, MS-SQL is a great database, I just dislike Windows. To that end, I made sure that working with MS-SQL from Ruby was done well at both the C extension layer with TinyTDS and the ActiveRecord adapter.
Sadly, I have personally stopped maintaing the later, but the C extensions are strong and even used by great projects like Sequel which if you had to some sort of raw ETL without the overhead of ActiveRecord is a great choice since it has adapter for all DBs, TinyTDS included.
Related
I am trying to practice writing simple SQL queries but I can't connect to my school account on Microsoft SQL Server Studio because they delete your database once you finish the class. I downloaded MySQL but I wasn't sure if I could practice queries on it or not. Any answers would be great, thanks!
The syntax and built-in functions are not identical, but they are similar for many things. For example, SQL TOP, LIMIT, or ROWNUM clauses is a case where they diverge.
Personally, I’d recommend taking a look at what w3schools.com has for SQL (and MySQL) resources. They have a ton of info to get you going, tutorials, references, etc. They also have “Try It Yourself” modules where you can use a playground database they provide to practice executing in the language your looking at material for. In cases where the SQL Server and MySQL (and other languages) syntax differs, w3schools shows examples of both (all that they support) like in the example I mentioned at the top.
Snippet from the top of their SQL tutorial home page:
“Our SQL tutorial will teach you how to use SQL in: MySQL, SQL Server, MS Access, Oracle, Sybase, Informix, Postgres, and other database systems.”
I suggest SQLite. Why?
It is an embedded database, rather than something like MySql which stores folders of metadata. Sqlite stores only a single file. My reasons for beginning with Sqlite are as follows:
1) It is the default database for a lot of common applications (Django, Airflow, etc). Knowing it would come in real handy when learning these tools.
2) The download is not only much simpler, but the ide is much faster. Your complete database is also only a single file (very beginner friendly).
3) In memory databases. That's correct, you can spawn and delete databases in Sqlite within memory (or even delete the whole file with your OS file removal). Very useful for learning, data science, and on the fly OLAP.
4) It can store up to 140 TB of data. It is the perfect tool to load a csv to quickly analyze the data. Also, you can create a small database, compress the file, and send it to anyone! Sharing your whole database is really just sharing a file.
5) You can import sqlite into Python, C, C++, and start automating your queries. You can do this with MySQL too but there is more library downloading and reading to do. Do not use sqlite in production (multi threading limits) but it is great for ad hoc analysis (Jupyter notebooks), prototyping, and learning.
Overall, mysql is not the best tool for beginners (it's not even used in production as much as Postgres or SQL server). It abstracts too much from the user to even understand what the database represents or the query engine. Also, Sqlite is closer to standard ANSI than MySQL in my opinion (given all the syntactic sugar). Learn Sqlite, move to postgres, and then explore all the nosql, blockchain, etc. If you ever face MySQL, you'll pick it up in minutes. I guarantee, you will have a much easier time picking up sqlite!
I am working with a client who is syncing between SQL Server and MySQL containing the exact same schema and data. We want to centralize that data into one database. Other then performance and maintainability issues, what else is bad about the original design?
You can create a linked server instance in SQL Server, with the MySQL instance.
Despite being completely proprietary, one of the nice connectivity features offered in SQL Server is the ability to query other servers through a Linked Server. Essentially, a linked server is a method of directly querying another RDBMS; this often happens through the use of an ODBC driver installed on the server.
Refer This article : step-by-step process SQL Server Linked Server to MySQL.
Providing you grant the MySQL user you connect on behalf of proper permissions, you can write to the MySQL instance accouding to you. So you can update stored procedures to do an additional step to insert records into MySQL.
Much easier solution is to use commercial application - Omega Sync from Spectral Core
Omega Sync can compare and synchronize both database schema and table data. You can even synchronize data of heterogeneous databases (for example, compare your local SQL Server database with a MySQL replica on your web site - and synchronize all the differences in just a few minutes).
on the otherhand I think you've already mentioned what possible problems you may encounter when synchronizing 2 db at the same time aside from this two I think it would be the resources. since there are different RDBMS working for the application they would also have a separate resources for each, like when I update a particular record of a user it still needs to check on which resource does it really exist, but I love to hear more from other people out there this is really an interesting topic to discuss. ;)
Is it possible to link tables from other databases (MS SQL, Sybase, etc.) inside a MySQL database, on a Debian server?
I am thinking this could be possible using ODBC.
Out of the box, I don't think so.
AFAIK, while its possible to implement your own functions in MySQL, these can only return single values - not tables of data.
It should be possible using a custom storage engine plugin. I believe there's one written for DB2 but a quick google turned up nothing for ODBC. It'd be a useful thing to have - so you could write one.
The only caveat is that neither the local MySQL nor the remote ODBC connected database would be able to optimise queries spanning engines properly - so it might be more efficient to handle the two systems in a progrmanning language which supports both.
I write MS Access / VB / SQL Applications, customized. One of my clients has a truly massive Access application I wrote them, and their number of active users have just expanded to over 15. Running into more data corruption issues, I am recommending they port to an SQL backend for stability. (Of course).
They would prefer to invest in a less expensive option and go with a Linux Server. I have used ODBC to hook an Access front to SQL backend plenty of times. But I have never touched Postgre.
I am looking for comprehensive detailed data on if this is a good strategic solution for a design plan, or if it is even a possibility. Perhaps there is an easier solution and I am barking up the wrong tree...
Yes, this is absolutely possible. I've not run into any major issues - the biggest I had was getting the Postgres boolean's to match up correctly - but it all depends on how you setup the ODBC connection and the actual application. I've found the ODBC connection stable and usable. If you really anticipate a larger number of users, you really ought to consider rewriting the whole app into something other than Access.
Overall, I'd definitely recommend Postgres as a backend via ODBC. Once you get used to a few of the differences, a lot of people really end up enjoying Postgres as a DB.
I've used both and I've found MySql to have several frustrating bugs, limited support for: IDE integration, profiling, integration services, reporting, and even lack of a decent manager. Total cost of ownership of MSSQL Server is touted to be less than MySQL too (.net environment), but maintaining an open mind could someone point out any killer features of MySql?
I've used MySQL in the past and I'm using MSSQL lately but I can't remember anything that MySQL has and MSSQL can't do.
I think the most killer feature of MySQL it's the simplicity. For some projects you just don't need all the power you can have with a huge system like MSSQL. I have an UNIX heritage and find the simple configuration file like my.ini a killer feature of MySQL.
Also the security system of MySQL is much less robust but it makes the job right for most of applications. I believe MySQL it's killer itself from this point of view, and should stay that way, letting young users being introduced to RDBMS with a simple view first. If your project gets big enough that you are considering switch to a more robust system, then MSSQL can pop as a possibility.
That's what happened to me.
The only thing I can think of, off hand, is locking. SQLServer has traditionally had poor locking strategy that has tripped many people up.
You should use what you prefer, ultimately. Its not as if MySQL is not good enough to compete with MS SQL, eg. Slashdot uses MySQL, so its hardly got problems with high-scalability performance.
Its killer feature though, is that it is free - you can deploy as many of them without worrying one fig about licensing issues. That's more important for the spread of software than anyone could imagine.
(TCO is a difficult thing to calculate - and is advice only ever given from paid consultants and other vested interests. Ignore that. MSSQL is expensive and MySQL is free.)
About 6 years ago I developed a custom e-commernce website using ASP and MySQL for the database. At the time MySQL was clearly a better choice than MSDE which had built in throttling which concerned me enough to use MySQL. Also the difference in coding between using MySQL and MSDE/SQL was not that different or much of a concern.
Now all these years later I'm trying to get the code converted to .NET and even after purchasing commercial MySQL drivers from CRLab. I found that, as you hinted, the IDE integration is just not up to par.
I will say that MySQL is doing a great job even with our database tables approaching 4GB. So when I switch to MSSQL I have to go ahead and get SQL Workstation or higher ($$$), and not use SQL Express which has a 4gb limit.
All of my experience has changed the way I develop new websites. Now, unless it is expected to have a lot of traffic. I use VistaDB and then upgrade to SQL Server if needed. VistaDB is syntax and datasource compatible with SQL Server. And the best part is it is only a single file for the database and a dll for your bin folder.
That's my two cents based on my personal experience with using MySQL in ASP and now .NET.
I work with MSSQL, MySql and PostGres regularly (using .net, java and PHP). One of my favorite things about about MySQL (esp. compared to MSSQL) is the ease with which you can run and restore full database backups.
MSSQL's model of using .bak files is really ugly and time-consuming (topic for another post.) But if you want to do somethign like automated testing, or automated build processes (that include building a db from scratch), MySQL can be a bit easier to deal with.
A few other points:
The management tools have gotten a lot better since the early days.
If you are interested in transactions, constraints, etc.. be sure you are defining your tables to use the InnoDB storage engine (instead of MyISAM which is designed for speed.)
I do miss MSSQL's schema generating tool, but I think there are equivalent tools out there.
We've used a Linux database server and a window's web server (for .net apps) with great success.
If you are using something like NHibernate or some other non-MS data abstraction layer, the case to look beyond MSSQL is stronger too...
Three points to consider; unfortunately the first two are contradictory:
1) .NET and MySQL were not designed to interact with one another, and there is no official support from either side. You're invariably going to encounter issues trying to use them together.
2) If portability off of Windows may ever be an issue (much .NET code runs quite nicely on other platforms via Mono), you'll want to avoid locking yourself too deeply to MSSQL. That doesn't mean not using it, but being careful that you don't rely on its particular quirks too much.
3) TCO is just a buzzword. It's complete nonsense when it's calculated by anyone other than you. Nobody can make such a calculation and honestly claim that it has any relevance outside their particular environment. There are too many factors, most of which have absolutely nothing to do with things like tool availability.
I've been using the community version of MySQL for alsmost 99% of my project. I like MySQL is that I can deploy via Xcopy and is powerful compare to other "xcopy-able" database server. I also wrote a wrapper to start and stop MySQL & Apache (like LAMP), but with my own implemetation and addon capability
MySQL probably has a lower TCO, since administration and configuration is more simple and straightforward than the Spaghetti GUI that MS SQL makes you do most of the configuration through, having to dig through hundreds of obscure properties dialogs to accomplish even basic administration tasks.
There is one area where MS SQL clearly excels over MySQL in my experience:
Integration with other technologies. MS SQL allows you to replicate back and forth with Oracle and MySQL databases, and provides SSIS for executing scheduled data transformations from other database servers.
There may be others, but I don't have experience with them.