I'm making data migration from MySQL to MongoDB and it's my first time, I followed these steps:-
select all data from SQL in the specific table and save it in one .CSV file.
set headers to the file data so every object has a key.
import the .csv file to DB using MongoDB compass.
the problem is the IDs in SQL away different from the MongoDB objectId, so how can I handle this?
note that the old database "SQL" has primary and foreign keys and my MongoDB schema has references too using objetcId.
We have an Android-Application communicating with a MySQL database via SOAP.
Now we were forced to create a webpage with Grails and of course we want to use the same database.
But how can we tell Grails to use our database structure for the domains?
Is there a way to merge these systems?
(The connection to the MySQL-Database is already established, but the two structures do not work together)
e.g. (in the least complicated case) we have a table "locations" with just one column 'name' which is PK. Grails would create a structure for the domain "location" with three columns 'id' 'version' and 'name'.
Grails creators had already thought about you and your case which is a common scenario when someone tries to move to grails with an existing enterprise infrastructure.
You need to have a look at db reverse engineer plugin which creates domain classes based on the existing table structure. You can use the domain classes once created by the plugin.
You can access your MySQL db by providing the datasource as such. In general, company wide datasource would be maintained (or you can create one if required), and use the datasource in Datasource.groovy.
GORM allows you a lot of configurations, you can disable the version control, change your primary key mapping and so on. In your example:
class Locations {
String name
static mapping = {
id column: 'name' //change the id from "id" to name
version false //remove version control, so it will not be added to your table
}
}
For the project we have a MySQL database. We want to use Mongo'S GridFS to store screenshots of each piece of software.
We're not sure if we should store the MySQL software id in the mongo file collection or to store the mongo id in a MySQL table i.e. table screenshots would have software_id and mongo_id. MongoID would point to the collection of the screenshots.
We'll be using Doctrine ORM and Doctrine ODM in parallel.
Any ideas? What would be the best solution? In terms of synchronisation. Would we run into any problems?
Thanks
Assuming each sotware has many screenshots and each screenshot belongs to one software, I would put MySQL ids in MongoDB:
it will avoid having an additional table in MySQL referencing entities it
doesn't own
it should avoid some lookups too (when you need screenshots, you will only
request it with the software id in MongoDB instead of asking MySQL
first and MongoDB afterward)
To compare databases of different vendors (Oracle, SQL Server, DB2, MySQL, and PostgreSQL) how can I identify any object uniquely and do I need a catalog? For instance, In Java's DatabaseMetadata I should specify catalog and schema fooPattern at least.
Is it true that catalog is just an abstraction of data storage?
In Oracle:
server instance == database == catalog == all data managed by same execution engine
schema == namespace within database, identical to user account
user == schema owner == named account, identical to schema, who can connect to database, who owns the schema and use objects possibly in other schemas
to identify any object in running server, you need (schema name + object name)
In PostgreSQL:
server instance == db cluster == all data managed by same execution engine
database == catalog == single database within db cluster, isolated from other databases in same db cluster
schema == namespace within database, by default public is used
user == named account, who can connect to database, own and use objects in each allowed database separately
to identify any object in running server, you need (database name + schema name + object name)
In MySQL:
server instance == not identified with catalog, just a set of databases
database == schema == catalog == a namespace within the server.
user == named account, who can connect to server and use (but can not own - no concept of ownership) objects in one or more databases
to identify any object in running server, you need (database name + object name)
In Microsoft SQL Server:
server instance == set of managed databases
database == namespace qualifier within the server, rarely referred to as catalog
schema == owner == namespace within the database, tied to database roles, by default dbo is used
user == named account, who can connect to server and use (but can not own - schema works as owner) objects in one or more databases
to identify any object in running server, you need (database name + owner + object name)
So I think answer to your questions is:
It depends on implementation, whether catalog name is needed to identify objects. The meaning of catalog, schema and database vary from one implementation to another.
Yes, a catalog is an abstraction of data storage. I think it should be also defined as a self-contained isolated namespace, but not all SQL engines do it.
Database and schema are pretty well defined by all vendors. Catalog is sometimes synonymous to "database" (at least in Oracle and Postgres), sometimes synonymous to "schema", and sometimes synonymous to both. The term catalog also often means metadata collection (aka system tables).
Schema is what programmers should use to organize artifacts in SQL database as it represents a logical namespace with access control layer.
For DB2, schema is used as namespaces. So if you want to uniquely identify an object in a database you would say *schema.object_name*. This is a very handy way to achieve multitenancy. You can have a separate schema for each tenant in your database. This provides for good separation of concerns from both security as well as management aspects. You can have 32K schemas in a single DB2 database.
A catalog in DB2 is simply a collection of system tables that contain metadata about the database. In general, it is considered a bad practice to access catalog objects directly. It is best to use the facilities provided by your API (e.g. JDBC) to explore the catalog and the metadata it contains.
DB2 also has other abstraction layers. You can have multiple instances of DB2 running on the same machine. Each instance can manage 256 separate databases (each with 32K schemas). The number of DB2 instances on a server is limited only by the amount of memory you have available. At one point in time we had 120 instances of DB2 (each with one database and 10 connections) running on Amazon EC2 m1.large.
You can also have multiple installs of DB2 on a single server. it is useful when testing a new version you plan to migrate to. I do find it confusing though often forgetting to switch to the right install.
What is mentioned here about mysql in post by filiprem seems to be incorrect. As per following links, in mysql the jdbc catalog corresponds to database. The jdbc schema is not supported .
http://forums.mysql.com/read.php?39,137564,137629#msg-137629
http://bugs.mysql.com/bug.php?id=23304
http://books.google.com/books?id=a8W8fKQYiogC&pg=PA25&lpg=PA25&dq=jdbc+catalog+schema&source=bl&ots=oj0HAA91zL&sig=vRjgPLV_3J6o2kqh6epwvZNZgcM&hl=en&sa=X&ei=3k7zT-_qBueW2AXSjdDkAw&ved=0CFYQ6AEwAg#v=onepage&q=jdbc%20catalog%20schema&f=false
I'm sharing my results in the point of client(driver)'s view.
product: result of the getProductName()
c_term: result of the getCataglogTerm()
s_term: result of the getSchemaTerm()
T_CAT: distinct values of TABLE_CAT from the result of getTables(null, null, "%", null)
T_SCHEM: distinct values of TABLE_SCHEM from the result of getTables(null, null, "%", null)
product
c_term
s_term
T_CAT
T_SCHEM
Apache Derby
CATALOG
SCHEMA
<empty>
SYS SYSIBM
H2
catalog
schema
TEST
INFORMATION_SCHEMA
HSQL Database Engine
CATALOG
SCHEMA
PUBLIC
INFORMATION_SCHEMA, SYSTEM_LOBS
SQLite
catalog
schema
null
null
MySQL
database
<empty>
performance_schema, information_schema
null
MariaDB
database
schema
information_schema
null
PostgreSQL
database
schema
pg_catalog, information_schema
pg_toast
I have three databases with exactly the same schema (SAP Business One databases). In this databases I have an item masters table connected to a warehouse stock table via the item code. Can I have just one Entity framework model that has only one item master object and one warehouse stocks object which draws data from the 3 databases?
The items are the same in the three databases but they have different warehouse codes.
I don't know if I have made myself clear.
If you want single EF model which will simultaneously load data from three databases then answer is no. If you want single EF model which can be used for all three databases the answer is yes but all your databases must use same database provider (server) and must have exactly the same schema of mapped tables.
The whole magic in this case is in connection string which can connect only to single database and cross database calls are not allowed.
If you need the first scenario you can try to hide unions and cross database queries in views and map those views in your model. This have two disadvantages:
Relation between views are not allowed in SQL Server but you can create the relation in EF model
Views are read only in EF model. If you want to modify data the best way is mapping stored procedures which will do that.