I am just trying to use flyway for the first time. So I put relevant clarifications as one post here. Please apologize. Am trying to make our two development test dbs (oracle) as sync or maintained with version. I have below clarifications on that.
1.Practically we have around 4000 objects in our db. Is this tool compatible and fast enough to handle this many objects?
We don't want to maintain data level version control for all the tables. For examples for transaction tables we don't want to sync production and development. Rather some configuration tables or master tables data needs to be maintained. Is it possible?
Let us by assume example db1 will be considered here as production and db2 will be considered as development. For that should we have to generate a SQL script manually that includes the entire DDL and all tables dml for db1? or flyway has command/option to do that?
Please clarify the above questions or guide me any documentation to refer to try in test set up to familiarize before to implement in actual project.
Thanks in Advance
Balaji
Related
I'm new to Azure and started an Azure Mobile App Quick-Start (.NET) project.
I'm studying on this blog wrote by Adrian Hall:
https://shellmonger.com/2016/05/09/30-days-of-zumo-v2-azure-mobile-apps-day-18-asp-net-authentication/. However, I've been confused by the explanation saying that:
Since this is Entity Framework, I would normally need to do an Entity
Framework Code First Migration to get that field onto my database. You
can find several walk-throughs of the process online. This isn’t an
Entity Framework blog, so I’ll leave that process to better minds than
mine. Just know that you have to deal with this aspect when using the
ASP.NET backend.
On the next page, https://shellmonger.com/2016/05/11/30-days-of-zumo-v2-azure-mobile-apps-day-19-asp-net-table-controllers/
The demonstration was using SQL syntax to create/manage the Azure SQL Database, such as: CREATE TABLE... and CREATE TRIGGER... and etc.
So, my question is, with either SQL(like the blog sample shown) or Entity Framework:1) Are they both able to do the exact same stuff?2) Should I only choose one of those methods only?
All the methods discussed (code first, model first, database first) provide you with a way to create a SQL database and update the data within it. The end result is the same - a database with data.
The method you pick tends to rely on where you prefer the 'intelligence' for your data to live - with the database or with the code.
Do you already have an existing database you'll be using?
Go database first, so you can automatically generate code and classes from the database.
Do you know SQL? Do you prefer to use your database for data only (i.e. no stored procedures or validating data inside the database)?
Go code first, you have full control of your model from the Code, and its a bit easier to keep databases in sync with your application.
There are a few more considerations that can help skew you to a different method. You can take a look at this blog post from Roland about the pros and cons of each approach.
There's also a StackOverflow thread that summarizes the differences between the methods.
Is it possible to build an ASP.NET website using EF where each customer logging in has separately stored data? We have customers demanding that their data won’t be stored in the same tables as other customers’ data.
I’ve read that EF can’t work with several databases but is it possible to switch database at runtime depending on input parameters? I have a feeling it won’t be possible since the migration features are tightly connected to the database being used, but I'm not sure.
One solution could be to have a separate website deployment and database for each customer. They’ll get separate domains to access but that’s not a problem. But this solution feels a bit clumsy if you’re having many customers, especially with deployment and future upgrades.
Am I missing some smart ways of solving this or is this a very tricky issue?
is structure (of the db) the same ?
if so you could switch connections - not w/o issues though, but should work. For details on how that should be done check the long discussion we've had here (and linked previous questions etc.)...
Code first custom connection string and migrations without using IDbContextFactory
I'd like to know the best architecture.
We have a web application running different domains. Each domain has its own MySQL database but the db structure is the same for all of them.
We have a web application for the visible part of the application.
We have a dataLogic project
We have a dataEntities project
We have a dataAccess that contains only the methods to connect to the data base.
Before we called stored procedures on a database. But we had to change it because the performance was bad. Also, the problem was that every change we made we had in a stored procedure we had to copy to every database.
We are thinking in using a WebService to retrieve the data. Every domain can call the web service with a connection string and connect its database to retrieve data. This way when we change a SQL query we only have to compile the webService and change it, we don't have to change versions on multiples domains.
Also, what do you think about the SQL queries? Since we don't want to keep using stored procedures, what is the best way to do it? Directly from code?
Thanks
T
If you have multiple Database servers you will have to make Structural changes from one DB to another one way or another. There are many tools to change Database structures. These tools will look for differences between Schema, and will either generate the SQL code for you, or do the changes by itself (it depends a lot in the tool, there are powerful ones and not so powerful ones). Please do take a look at Toad for MySql. Now, for the Data changes, you may want to replicate the data from one Database to another. This is done through Replication.
We are thinking in using a WebService to retrieve the data. Every
domain can call the web service with a connection string and connect
its database to retrieve data.
This sounds like a good idea and since you already have "dataAccess" and "dataLogic" projects, it should not be too hard to make the services.
Also, what do you think about the SQL queries? Since we don't want to
keep using stored procedures, what is the best way to do it? Directly
from code?
I don't think it is a good practice to have the SQL queries directly into your code, but it depends in a lot of things, so I would suggest Stored Procedure vs Hard-Coding the queries, or LinQ (Entity Framework 4.1).
Good luck with your project and I will take a look at this thread frequently to see what you end up doing.
Have fun!
Hanlet
I am looking for a good change management application for use with SQLite. In the past I have used SQL Data compare by Redgate, but I have been unable to find anything similar that supports SQLite.
I need to update a fairly large encrypted SQLite database (~1,000,000 rows and 74MB). If possible I would like to generate some scripts to just update the changes rather than force users to download a whole new copy of the database. The version of SQLite we are using is 3.6.23.1. Thanks in advance for any recommendations :)
Have you tried SQLite Compare? It's freeware, and I have used it to compare schemas/data. I think it will also generate SQL update scripts for you too.
We have an ASP.NET app with SQL Server & it is a photo & video sharing site.
Details of photos and videos are stored in tables & the files are in the file system.
Database has 75 tables and 225 stored procedures. The app will be ready for production deployment within next 6 months.
Due to longer time growth concerns, we decided to switch to NoSQL (MongoDB) database.
We have few questions regarding the best way to approach this:
Is it better to deploy the app with SQL Server backend and migrate to NoSQL later?
OR re-architecture now and rewrite/recreate database, tables, procedures and data layer
How difficult will it be re-architecture/recode with MongoDB? Any tools or BKMs?
EDIT:
Our app is Youtube+Flickr type site where user will share photos and videos with lots of comments, tags and ratings (photo\video & comments).
Is NoSQL a better database to move to? Reason for moving: cost + read query speed
Please help me with you valuable advise.
Thank you very much.
Change is always exponentially more expensive the later it is introduced to a project. This is a core principle of software engineering. You should do this now.
That said, I question your long-term vision. Relational databases, used properly, have a lot of performance in them.
This question raises more questions than answers.
Have you benchmarked your current implementation in terms of requests/responses?
Why MongoDB out of all possible NoSQL databases? (Don't get me wrong, I love Mongo, but love and hype should not weigh in technology choices)
Are you certain you will get the large userbase you're expecting? Why are you so certain?
Using stored procs seems to tip off that you aren't using an ORM? Why not?
Generally, I'm against these types of re-architectures. Firstly, you need to get your whole team acclimated to how Mongo affects development. Secondly, your ops team needs to get acclimated to how to deploy and maintain a Mongo installation. More likely than not, this will prevent you from launching in a timeline you want to launch.
I'd say that you should probably launch as is, fix the ORM part if you aren't using one, benchmark your app, benchmark a prototype of your app backed by Mongo and if the performance advantages are so big that it warrants the pain of re-architecture do it.
To your latter question, there aren't any tools right now, as far as I can tell, that'll automate or semi-automate the database import/export from SQL Server to Mongo. There are barely tools to do that for MySQL.
I've done such a migration a few month ago, during the early developement stage of a website in ASP.NET. It was a hard decision, but I could concentrate on that migration. The reason why I did this migration was the ORM that I couldn't trust anymore and some very slow queries that I had no idea how to optimize.
During coding phase, what I figured out was : I was spending a lot of time with the data model in SQL Server (using Entity) and all the plumbery code.
Now, no more store procedures (C# and Linq code instead), no more 2 layers to maintain (the code is the model).
My small experience says : The earlier the better but don't get me wrong, before migrating you really have to think in Document rather than in RDBMS. This means you may have to partially change the businness DataModel to correctly utilize MongoDB features, otherwise you could get bad performances and Mongo DB is useless for bad models.
Another point is the admin stuff. You'll have to quickly learn Mongo DB admin to be up to speed. And even if the tools are good, they completely differ from SQL Server tools.
In conclusion, If you're convinced MongoDB is your future data store and search database,
(and it was in my case), read documentation, take time to do some Proof Of Concept. Then you can think Document and load test you new model.
Your core question appears to be whether to make the switch to MongoDB now, or deploy on SQL and go to MongoDB in a future release.
You do not appear to be using an ORM (e.g. NHibernate, Entity Framework.) Setting other concerns aside, if you're convinced that you want to go to NoSQL, then I would do it now rather than later. Unless you integrate a Provider model for your data access, changing the underlying data access strategy after it is already established would be difficult.
I agree. Switching now is better, if only to avoid the data migration headache switching post-deployment will require.