Documentation on Azure Search says I can use Azure Sql server as a datasource(https://azure.microsoft.com/en-us/documentation/articles/search-howto-connecting-azure-sql-database-to-azure-search-using-indexers-2015-02-28/). Can I do the same with an on-premise SQL server?
I have a typical relational structure like
User Table -> Address Table
User Table -> UserDetails table etc..
All linked to each other via foreign keys. My search should end up with an UserId, so I can link to my UserDetailsPage.aspx?UserId=xxx
What will be the best suggested way to build the datasource? Should I Create a view and apply change tracking on it? or Should I create a different datasource for each table and sync the concerned index?
Please shed some light on best practices in a typical relational database scenario.
you would need to allow the IP address of your search service to connect to your on-prem DB.
In terms of view vs. multiple indexers targeting the same index - both approaches might work. What info will your users be searching on - address, details, or both? If it's only one of those, then you wouldn't have to index both tables.
Keep in mind that if you decide to index a view joining both tables, you won't be able to use SQL integrated change tracking, and will have to rely on a rowversion or timestamp column in the view.
HTH
Related
. I have two databases in same azure sql server .i want that both database interact to each other using trigger. i.e If any record is inserted in Customer table of first database the trigger gets fired and record is inserted in another database.
We had / have the same problem with triggers that we use for insert-update-delete where we write a record to Database-1 that has the primary table, but also updates Database-2 where we hold "archive" versions of the tables.
The only solution we have identified and are testing is to bring all of the tables into a single database and separate the different tables under separate database schemas in the one database.
Analysis so far of this approach looks promising.
I think what you're trying to do is not allowed in Sql Azure. From my expertise what you are trying to do is a bad practice on-premise as well (think backups-restore and availability issue scenarios).
You should move the dependency in the application and have the application update both databases, as appropriate.
Anyway, if you want to continue with this approach please take a look over Elastic Query feature: https://learn.microsoft.com/en-in/azure/sql-database/sql-database-elastic-query-overview
Please let me know if I can help with something
I have a lot of views and tables connected in Microsoft SQL Server. I want to check all the useless columns I have in the native tables. Is there a way to perform an automatic check if a column in a table is used or not in other tables?
Create a database diagram in SQL Server Management Studio. From here you can analyze how the tables/columns are related or not. Info here
Do a business model analysis and see which values are used, which are deprecated and start from there.
If you do any changes on the database, these changes have to be projected in any code connecting to that database.
Do not remove columns in tables just by looking at a database diagram. You would destroy any object-relational mapper.
I'm am currently developing one project of many to come which will be using its own database and also data from a central database.
Example:
the database "accountancy" with all accountancy package specific tables.
the database "personelladministration" with its specific tables
But we also use data which is general and will be used in all projects like "countries", "cities", ...
So we have put these tables in a separate database called "general"
We come from a db2 environment where we could create foreign keys between databases.
However, we are switching to MS SQL server where it is not possible to put foreign keys between databases.
I have seen that a workaround would be to use triggers, but I'm not convinced that is a clean solution.
Are we doing something wrong in our setup? Because it seems right to me to put tables with general data in a separate database instead of having a table "countries" in every database, that seams difficult to maintain and inefficiënt.
What could be a good approach to overcome this?
I would say that countries is not a terrible table to reproduce in multiple databases. I would rather duplicate static data like that than use more elaborate techniques. There is one physical schema per database in sql server and the schema can not be shared. That is why people use replication or triggers for shared data.
I can across this problem a while back. We have one database for authentication, however, those users have to be shared across multiple applications some of which have their own database.
Here is my question on this topic.
We resorted to replication and using an custom Authentication/Registration service agent to keep the data up to data.
Using views, in what Sourav_Agasti suggested in his answer, would be the most straight forward approach for static data. You can create views and indexed views and join data from databases on linked servers.
Create a loopback linked server and then create a view(if required, on each database) which accesses the table in this "central database" through this linked server. There will be a minor performance impact but it more than enough compensates by being very simiplistic.
I'm part of a team looking to move from our relational data warehouse to a SSAS cube. With our current setup we have an "EmployeeCache" table (basically a fact) which is a mapping from each of our employee ids to their viewable employee ids. This table is joined in our model to our DimEmployee table so that for every query that needs personally identifiable information the DimEmployee records are filtered. The filter is applied from a session variable that is the user id which is making the query.
All of the examples we researched to provide dimension level security in a SSAS cube have required the use of Windows managed security. The systems that create the data that is being analyzed handle their own security. Our ETLs map the security structure into the aforementioned EmployeeCache and DimEmployee tables. We would like to keep this simple structure of security.
As we see it there is no way to pass in session values (aside from using the query string which we're not seeing it possible with Cognos 10.1) to the cube. We're also not seeing any examples out there on security which does not require the use of Windows auth.
Can someone explain if there is a way to achieve dimensional security as I have previously described in a SSAS cube? If there is no way possible could another cube provider have this functionality?
Two thoughts. Firstly, SSAS only supports windows authentication (see Analysis Services Only Windows Authentication) and this is unchanged in Sql Server 2012. But you can pass credentials in the connection string to analysis services. Secondly, could you alter the MDX of every query and add a slicer to restrict the data to only the data a user should see?
I’m after a bit of advice on the best way to go about this is SQL server 2008R2 express. I have a number of applications that are in separate databases on the same server. They are all “plugins” that use a central staff/structure list that will be in a separate database. The application is in the process of being migrated from JET.
What I’m looking for is the best way of all the “plugin” databases being able to see the central database and use those tables in standard queries and views etc.
As I’m using express that rules out any replication solution and so far the only option I can think of is to use triggers or a stored procedure to “push” out all the changes to the plugins. The information needs to be populated on a near enough real time basis however the number of changes will be very small maybe up to 100 a day and the biggest table only has about 1000 rows at the moment (the staff names table).
Hopefully that will cover all everything but if anyone needs any more details then just ask
Thanks
Apologies if I've misunderstood, but from your description it sounds like all these databases are hosted on the same instance of SQL Server - it's your mention of replication that makes me uncertain.
Assuming that's the case, you should be able to replace any copies of tables from the central database which are held in the "plugin" databases with views or synonyms which reference the central tables directly, since SQL server allows you to make references between databases on the same server using three-part naming (database_name.schema_name.object_name)
For example, if each plugin db has a table StaffNames, you could replace this with a view by dropping the table, then creating a view:
drop table StaffNames
go
create view StaffNames
as
select * from <centraldbname>.<schema - probably dbo>.StaffNames
go
and your code should continue to work seamlessly, as long as permissions are set up.
Alternatively, you could replace all the references to the shared tables in the plugin databases with three-part name references to the central database, but the view method requires less work.