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 6 years ago.
Improve this question
I'm seeking any best-practice documentation you might have that describes your recommendations for deploying applications which have been built on CodeFluent Entities. We're using CodeFluent (licensed through the University of Western Sydney) for our projects with the Australian Consortium for Classification Development (https://www.accd.net.au) and would like to avoid using other third-party tools if possible. I've had a quick look on SoftFluent's new website's Knowledge Center but haven't found anything which addresses this issue
CodeFluent Entities provides two ways to update the database schema, and SQL Server also has one.
Pivot Runner
http://blog.codefluententities.com/2013/10/10/the-new-sql-server-pivot-script-producer/
Generation time: The SQL Server Pivot Script Producer generates an XML file that describes the schema of the database (table, columns, keys, stored procedures, etc.).
Deployment time: The Pivot Runner read this file and update the target database to match the target schema.
You can run the PivotRunner using the provided client CodeFluent.Runtime.Database.Client.exe or use your own program:
PivotRunner runner = new PivotRunner(pivotPath);
runner.ConnectionString = "<SQL Server connection string>";
runner.Run();
SQL Server producer diff engine
The SQL Server Producer generates a diff script. So you can run this script on the target database.
Data-tier Application (dacpac)
not CodeFluent Entities related
A data-tier application (DAC) defines all the SQL Server Database
Engine schema and instance objects (such as tables, views, and logins)
required to support an application. A DAC is built into a DAC package,
which is an XML file containing a manifest that defines all the
Database Engine objects used by the application, and is used to deploy
the DAC. A DAC simplifies the management of the data-tier objects by
providing a single unit for deployment and management.
https://technet.microsoft.com/en-us/library/ee240739.aspx
https://technet.microsoft.com/en-us/library/ee635209.aspx
Related
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 4 years ago.
Improve this question
Are there any tools that can compare the schema of two Postgres databases to an SQL script and is able to handle declaratively partitioned tables correctly?
I've been searching high and low. DataGrip 2018.2 is able to generate DDL that correctly reproduces a declaratively partitioned table and all of the partitions, but it does not generate a script. Migra (a Python tool) generates a script, but treats partitions as standalone tables.
I had a similar issue but it was related to inheritance table in postgresql and I tried the following 2 options with success:
1st option:
pg_dump -s db1> first
pg_dump -s db2> second
diff first second
(obviously wont generate SQL to remedy the differences)
2nd option:
TiCodeX SQL Schema Compare
(https://www.ticodex.com)
It's a nice tools that runs in Windows, Linux and Mac and can compare the schema of MS-SQL, MySQL and PostgreSQL database.
Easy to use and effective. It may help you.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I am getting confused about PostgreSQL. In some places people are saying it's NoSQL, and in some places people are saying it's not NoSQL. I have seen something Postgres Plus which is actual NoSQL.
Can you tell me what is true?
You have been confused my marketing and buzzwords.
“NoSQL” is a buzzword describing a diverse collection of database systems that focus on “semi-structured” data (that do not fit well into a tabular representation), sharding and high concurrency at the expense of transactional integrity and consistency, the latter being among the basic tenets of relational database management systems (RDBMS).
Since SQL is the language normally used to interact with an RDBMS, the term “NoSQL” is used as a name for all these systems. Perhaps the name was also chosen because SQL, being verbose and often hard to understand, evokes negative reactions in many programmers.
Now PostgreSQL, like many other RDBMS, has added support for JSON data, which is the most popular format for semi-structured data commonly stored in NoSQL systems. Now you can say that PostgreSQL supports a certain feature commonly found in NoSQL databases.
Still, SQL is the only way to interact with a PostgreSQL database, so you couldn't call it a NoSQL database and keep a straight face unless you were in marketing.
Postgres Plus is a closed source fork of PostgreSQL, so the same applies to it.
PostgreSQL is not NoSQL.
PostgreSQL is a classical, relational database server (and syntax) supporting most of the SQL standards.
On a sidenote, I suggest doing some research into the differences and advantages. They both have a solid place and time.
PostgreSQL prides itself in standards compliance. Its SQL implementation strongly conforms to the ANSI-SQL:2008 standard. It has full support for subqueries (including subselects in the FROM clause), read-committed and serializable transaction isolation levels. And while PostgreSQL has a fully relational system catalog which itself supports multiple schemas per database, its catalog is also accessible through the Information Schema as defined in the SQL standard.
Source
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Please help me to setup connectivity from PostgreSQL to Informix (latest versions for both). I would like to be able to perform a query on Informix from PostgreSQL. I am looking for a solution that will not require data exports (from Informix) and imports (to PostgreSQL) for every query.
I am very new in PostgreSQL and need detailed instructions.
As Chris Travers said, what you're seeking to do is not easy to do.
In theory, if you were working with Informix and needed to access PostgreSQL, you could (buy and) use the Enterprise Gateway Manager (EGM) and use the ODBC driver for PostgreSQL to allow Informix to connect to PostgreSQL. The EGM would do its utmost to appear to be another Informix database while actually accessing PostgreSQL. (I've not validated that PostgreSQL is supported, but EGM basically needs an ODBC driver to work, so there shouldn't be any problem — 'famous last words', probably.) This will include an emulation of 2PC (two-phase commit); not perfect, but moderately close.
For the converse connection (working with PostgreSQL and connecting to Informix), you will need to look to the PostgreSQL tool suite — or other sources.
You haven't said which version you are using. There are some limitations to be aware of but there are a wide range of choices.
Since you say this is import/export, I will assume that read-only options are not sufficient. That rules out PostgreSQL 9.1's foreign data wrapper system.
Depending on your version David Fetter's DBI-Link may suit your needs since it can execute queries on remote tables (see https://github.com/davidfetter/DBI-Link). It hasn't been updated in a while but the implementation should be pretty stable and usable across versions. If that fails you can write stored procedures in an untrusted language (PL/PythonU, PL/PerlU, etc) to connect to Informix and run the queries there. Note there are limits regarding transaction handling you will run into in this case so you may want to run any queries on the other tables using deferred constraint triggers so everything gets run at commit time.
Edit: A cleaner way occurred to me: use foreign data wrappers for import and a separate client app for export.
In this approach, you are going to have four basic components but this will be loosely coupled and subject to proper transactional controls. You can even use two-phase commit if you want. The four components are (not providing a complete working example here but at least a roadmap to one):
Foreign data wrappers for data import, allowing you to see data from Informix.
Views of data to be exported.
External application which manages the export aspect, written in a language of your choice. This listens on a channel like LISTEN export_informix;
Triggers on underlying tables which make view of data to be exported which raise a NOTIFY export_informix
The notifications are riased on the commit and so basically you have two stages to your transaction in this way:
Write data in PostgreSQL, flag data to be exported. Commit.
Read data from PostgreSQL, export to Informix. Commit on both sides (TPC?).
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 2 years ago.
Improve this question
I have an upcoming requirement, and I'm unsure if EF is the right approach.
Essentially I have a Web Service Contract to implement, that has a handful of methods that return specific classes (DataContract classes with DataMember'd properties so they serialize correctly). The data that makes up the classes will be the result of queries against a backend database.
At the lowest level, I know I can just write some stored procs in the database that will return data rows that I can manually wire up to the custom classes, and call the stored procs from within a Data Layer class (calls stored procs, returns custom classes).
I'm wondering if I can use ADO.NET Entity Framework for this, however my understanding that this creates Entity classes from the database tables. My custom classes don't resemble any of the database tables. The stored procs perform aggregations and table joins to produce the classes.
Am I missing something here from what's possible with the EF? Or would I be better just going with stored procs / manually wiring up the custom classes in a data layer?
The Web Service will be hosted in SharePoint 2010 therefore I'm limited to ASP.NET 3.5. I think I'd be using Patterns and Practices to access the data layer, unless there are better ideas out there.
Given that you have indicated that you can only use .NET 3.5, you would be using EF 1.x which wasn't widely accepted in the ORM community.
EF 4.x is much improved, but unfortunately requires .NET 4.
DAAB is certainly an alternative, but you will still need to map out your Service entities from the data (i.e. DAAB isn't an ORM)
IMO EF comes into its own when used with LINQ, especially when used with queries - if you find that you are writing many SPROCs of the form GetXXXByYYY (or using lots of ad hoc or dynamic sp_executesql) to populate your entities, then a LINQ enabled ORM makes a lot of sense. However, if you only have a few heavy hitting PROCs which have well defined interfaces, then an ORM may be overkill.
If the object model of your application remarkably differs from the data model in your database then I'd stick to the classic ADO.Net + stored procedures for aggregations and table joins. My opinion is that any ORM brings more trouble than benefit in such case.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Is this like an “embedded” database of sorts? A file containing a built in database?
SQL Server databases use two files - an MDF file, known as the primary database file, which contains the schema and data, and a LDF file, which contains the logs. See wikipedia. A database may also use secondary database file, which normally uses a .ndf extension.
As John S. indicates, these file extensions are purely convention - you can use whatever you want, although I can't think of a good reason to do that.
More info on MSDN here and in Beginning SQL Server 2005 Administation (Google Books) here.
Just to make this absolutely clear for all:
A .MDF file is “typically” a SQL Server data file however it is important to note that it does NOT have to be.
This is because .MDF is nothing more than a recommended/preferred notation but the extension itself does not actually dictate the file type.
To illustrate this, if someone wanted to create their primary data file with an extension of .gbn they could go ahead and do so without issue.
To qualify the preferred naming conventions:
.mdf - Primary database data file.
.ndf - Other database data files i.e.
non Primary.
.ldf - Log data file.