Joining QuerySets from different tables - sql-server

I am trying to use Django to create reports from a legacy MS SQL application. The application includes two identical schemas for storing tickets, one called Requests, the other ArchiveRequests.
I would like to create a single QuerySet that holds data from both tables. This can be done in T-SQL like this
SELECT TOP 100 *
FROM [AmCatHDSQL].[dbo].[ArchiveRequests]
UNION SELECT *
FROM [AmCatHDSQL].[dbo].[Requests]
However trying to union them using the | operator raises an AssertionError, Cannot combine queries on two different base models.
Is there a way to tell Django that these models are identical and can be unioned, or is there a better way to reference these (as a single model?)

Related

Mapping multiple objects in dapper using Split-on and Query Multiple together

Consider Role-Employee-Address
An employee can have only one role but can have many addresses. So using split on is not efficient as we may get the duplicates of roles and employee. We can use query multiple, but i feel if there is a way we can capture the role and employee together in one result and address in another, then that would be better.
In that case, instead of returning role and employee separately, we can directly join both in a single query and split on some column while mapping.
I'm expecting something like this
string query = "StoredProcedure";
using (var multi = connection.QueryMultiple(query, null))
{
empRole = multi.Read<Employee,Role>().Single().SplitOn("Id");
add = multi.Read<Address>().ToList();
}
Is there any way we could do like this using both the techniques together?
Correct, you need a One-To-Many mapping which is not natively supported by Dapper, but can be easily implemented if the database you're using supports JSON. Here's an article I wrote (along with working samples) that shows how you can do it using SQL Server / Azure SQL:
https://medium.com/dapper-net/one-to-many-mapping-with-dapper-55ae6a65cfd4

Possible to name query results for future use without a table?

Working in SQL Server 2008 where I only have access to create queries, not tables or views. My question is related to structuring code better.
I have views provided that give me multiple data sets with too much information. I'm attempting to slim the data down for easier use and reference, with requested specifics.
My goal is to have (3) main queries that list all of the data that I need, and to reference and reuse the data for multiple reports.
Query 1 - Incidents: lists all of the detail on a call
Query 2 - Units: lists all of the detail on units responding to a call
Query 3 - 1stUnits: lists all of the detail on 1st responding units only.
Because each of these queries will have multiple CASE statements within them, I was looking for a way to name the actual query, and reference the query in SQL as Qry1Calls or Qry2Units without an extensive subquery, within a query.
I've searched a bit, and found nothing.
It would be a lot easier to select Qry1 and Qry3 where id's match and filter those results by parameters.
Is this possible? I'm transitioning from Access with some SQL to full fledge SQL.
What you are looking for is probably Common Table Expressions (CTEs)
Read about them here:
https://msdn.microsoft.com/en-us/library/ms190766(SQL.90).aspx
Reference for the with keyword and examples here:
https://learn.microsoft.com/en-us/sql/t-sql/queries/with-common-table-expression-transact-sql

Finding columns used in a calculation in a SQL Server view

I'm trying to put a data dictionary together for a client using SQL Server MDS. In order to avoid tracking the specific location in the data warehouse/marts/source systems of the fields being defined, I'm hoping to use the system views as much as possible.
This works fine for tracking the fields themselves. However, the users' reports work off cubes built on views in the data marts, and I'm having trouble tracking the source of calculated columns.
Taking this view as an example:
CREATE VIEW [dbo].[vw_testing_colltable]
AS
SELECT colid, coldesc, firstadd + secondadd AS totaladd
FROM dbo.testing_coltable
Where in the system views can I determine that firstadd and secondadd are part of the view and they are used to create totaladd?
INFORMATION_SCHEMA.VIEW_COLUMN_USAGE lists firstadd and secondadd but not totaladd.
INFORMATION_SCHEMA.COLUMNS lists totaladd but not firstadd and secondadd.
sys.columns combines the two.

Cake2 - show data from 2 identical databases

i have quite large application with complex DB structure (lots of tables with foregin keys.. ).
This application exists in 2 instances ( so there are 2 schema-identical DB's ), every has different data (some data can be same like 'district').
I need to create third application for reading data only. This third application needs to read data from both databases, merging them and displaying them.
I need to by able to use existing application code for reading, sorting, filtering, paginating.
What is most effective way to achieve this in cakephp?
Thanks in advance
Possible solution:
- create your own data source ( extend existing Mysql )
- overload "read" method, in this overloaded method, merge records and return

Need a clever way to get orders from all stores while each store is in a different database

The setup
I have the following database setup:
CentralDB
Table: Stores
Table: Users
Store1DB
Table: Orders
Store2DB
Table: Orders
Store3DB
Table: Orders
Store4DB
Table: Orders
... etc
CentralDB contains the users, logging and a Stores table with the name of each store database and general information about each store such as address, name, description, image, etc...
All the StoreDB's use the same structure just different data.
It is important to know that the list of stores will shrink and increase in the future.
The main client communicating with this setup is an API REST Service which gets passed a STOREID in the Header of each request telling it which database to connect to. This works flawlessly so far.
The reasoning
Whenever we need to do database maintenance on one store, we don't want all other stores to be down.
Backup management should be per store
Not having to write the WHERE storeID=x every time and for every table
Performance: each store could run on its own database server if the need arises
The goal
I need my REST API Service to somehow get all orders from all stores in one query.
Will you help me figure out a way to do this without hardcoding all storedb names? I was thinking about a stored procedure on the CentralDB but I was hoping there would be other solutions. In any case it has to be very efficient.
One option would be to have a list of databases stored in a "system" table in CentralDB.
Then you could create a stored procedure that would read the database names from the table, loop through them with cursor and generate a dynamic SQL that would UNION the results from all the databases. This way you would get a single recordset of results.
However, this database design is IMHO flawed. There is no reason for using multiple databases to store data that belongs to the same "domain". All the reasons that you have mentioned can be solved by using a single database with proper database design. Having multiple databases will create multiple problems on the long term:
you will need to change structure of all the DBs when you modify your database model
you will need to create/drop new databases when new stores are added/removed from your system
you will need to have items and other entities that are "common" to all the stores duplicated in all the DBs
what about reporting requirements (e.g. get sales data for stores 1 and 2 together, etc.) - this will require creating complex union queries...
etc...
On the long term, managing and maintaining this model will be a big pain.
I'd maintain a set of views that UNION ALL all the data. Every time a store is added or deleted those views must be updated. This can be automated.
The views provide an illusion to the application that there is only one database.
What I would not do is have each SQL query or procedure query all the database names and create dynamic SQL. That would entail lots of code duplication and an unnecessary loss of performance. This approach is error prone. Better generate code once in a central place and have all other SQL code reference that generated code.

Resources