Hi I would like to be able to update a view to point to a table in a different schema as in example below, change SCHEMA1 to SCHEMA2. No other change to the SQL.
Can anyone suggest an efficient way to achieve this, ideally a string replacement.
I can do CREATE OR REPLACE FORCE VIEW and provide the list of fields. This doesn't seem a good option as I have about 40 views re repoint.
CREATE OR REPLACE FORCE VIEW CUST.CustOrdersView as
SELECT field1, field2 etc.. from
SCHEMA1.CUSTOMER ;
Your problem is simply that you have hardcoded the schema name in the views' queries. Instead of that you could have created a synonym:
create synonym CUSTOMER for SCHEMA1.CUSTOMER;
Then in your view you would have simply referenced CUSTOMER.
To repoint the view to another schema you would have to change the synonyms:
create or replace synonym CUSTOMER for SCHEMA2.CUSTOMER;
That's still work but it's much easier to generate those statements from the data dictionary views than it is to change all the view queries.
(If there is a namespace clash - that is, if schema which owns the views already has an object called CUSTOMER - you would need to use a different name for the schema.)
You may not regard this as a helpful answer, because it doesn't really solve your current problem, but it may help you avoid a similar situation in the future.
Related
I have a Laravel 8 application and am wondering how to solve the problem of how to solve a typical polymorphic issue. I have an Employee model. That Employee can be an ExecutiveEmployee or EntryLevelEmployee. There will be methods an ExecutiveEmployee has that an EntryLevelEmployee doesn't have and the inverse is also true.
Using Laravel 8, is it right to create a base Employee model (without a corresponding table?) and then create two models named ExecutiveEmployee and EntryLevelEmployee that inherit from Employee? This would also imply that both employee types will have two different database tables, even though there will be a lot of overlapping data.
Does it make sense to just have one Employee model and create a migration that has the employee type listed in the model? I am assuming that it's ok if an EntryLevelEmployee has some database attributes which are relevant to it that may or may not be relevant to an ExecutiveEmployee type here, or is that an incorrect assumption?
What's the correct way to model this in Laravel 8? I prefer to keep everything in one table because of how similar the models are. I do have to keep in mind that there will be data that one has that the other doesn't. There will be different accessor methods as well.
Is it possible to have everything in one employees table while utilizing multiple models? Meaning, if I create two models named ExecutiveEmployee and EntryLevelEmployee they would both query the underlying table employees?
UPDATE 1
The more I research, the more I think polymorphism is the incorrect approach here and what I might need is Single-Table Inheritance. This package seems to bring the capability to Eloquent. Would there be a good reason to not use this?
I would use polymorphic relationships in this case, because you are more flexible and have less coupling.
Using the Single Table Inheritance (STI), you can add type specific columns in the employees table and make them nullable. But think about adding/removing types in the future.
executive_employees
id - integer
executive_specific - string
entry_level_employees
id - integer
entry_level_specific - string
employees
id - integer
name - string
email - string
employable_id - integer
employable_type - string
As for the STI the same would be
employees
id - integer
name - string
email - string
type - string
executive_specific - nullable string
entry_level_specific - nullable string
So STI would be suitable when you don't have type specific columns. But you want to add specific behavior in your code. For example a User type (Admin, Author).
Even so, it's a matter of preferences.
It really depends on the state and behavior of your employee object.
Below are few points I will consider to make a decision
If your objects' states/properties are different then definitely you will create different models as your data will be stored in different tables.
If most states/properties are same and some are different, you can
consider storing all in one table/model and for the difference in
behavior create separate table like Ron Van Der Heijden has
suggested and you can consider query scope with that to make
transaction with database.
And another view will be
How many JOINs you will create if you will create different tables,
will that impact the performance and other stuffs, will it make your
code complex?
Can you make simpler relations and handle stuffs independently?
When you are making an API, will your
code make the api overworking? or you need to create too many request
for any operation?
These stuffs will decide how you will make a decision.
Update 1:
Another point I would like to add about the package you are thinking to use, consider using a parent key in table and you can define relationships in a single model.I do not think you need to use a package, you can define it yourself, I guess.
I don't understand why you don't create a simple one-to-many relation. Based on the information you provided, the polymorphic relation looks unnecessary. I think the right way is to create employee_roles table and relations. Then you can give different permissions to different employee types. There are several ways to do that. You can create a middleware to create route restrictions. You can check the role before executing a function in the controller, and run only if the employee has permission. You can use if-else in blade not to render the parts that can't be used by auth user etc.
If you have different “types” of employees, and each employee type should have different logic then yeah, that sounds like a polymorphic relationship.
Is it possible I can translate column name from one language to another.
For example:
In one of our application, DB columns named in polish.
I want, for example when I give select * from table_name. I can read column name in English.
Create view on the top of your original table and give access to your users just to the view. For the end users hide your real table. You can map columns from original table to view column names that will have national characters.
I think the quickest way to do this is to define views (some sort of wrappers over the tables). However, this will lead to extra maintenance, as each schema change in the source tables will require a change in the correspondent view.
I have a View in an SQL Server Database, which involves many different tables. I am using Linq to Entities to access the database, so I have no problem getting and showing view's result.
But the problem is when I want to modify some field in those results. As long as a view doesn't have a primary key, the Entity is read-only, so the question is:
Is there any way to modify the object with the view's data and save those changes in the corresponding tables?
Sorry for my english, but it's not my native language.
Thank you very much in advance!
There are some requirements for VIEW to be updatable. Take a look here. You say your view references many tables, so you have to implement INSTEAD OF trigger.
I am in the process building myself a simple Linq to SQL repository pattern.
What I wanted to know is, is it possible to set a default sort column so I don't have to call orderby.
From what I have read I don't think it is and if this is the case what would recommend for a solution to this problem.
Would the best idea be to use an attribute on a partial class on my model?
the default order is the clustered index on the table you are pulling from.
What are you wanting to sort on (without sorting on) ?
If you needed something other than having it sorted by the primary key, you could look at supplying a select statement for the table instead of using the runtime generated statement. Look at the properties on the table in the designer -- you should be able to override the runtime generated select, delete, and update statements. I don't personally recommend this, though, since I'm not sure how it will interact with other orderings. I think the intent is more along the lines of allowing you to use stored procedures if you want.
Another alternative would be to create a table-valued function or stored procedure that does the ordering the way you want and has the same schema as the table. If, in the designer, you drag this onto the table, you get a strongly typed method on the data context that you can use to obtain those entities according to the definition of the function/procedure instead of the standard select. Personally I think this introduces fewer maintenance headaches because it makes it more visible, but you do have to remember to use the method instead of the Table property for that entity.
I'm using Linq 2 Sql and I'd like to add a custom member on one of my data type. For example: I have tables Companies, Departments and Employees. Departments has a FK in Companies and Employess has a FK in Deparments. Very simple.
My goal is to add an EmployeeCount property on Company that will, of course, returns the number of employee in the company (by suming the number of employee in company's departments).
As you may know, it's really trivial to do: just add a member on the partial class and do the stuff. The problem is, I now want to sort on this custom member.
How can I write this custom member for Linq to be able to translate the logic into a valid SQL orderby? I tried with a SPROC but did not success.
Any help appreciated!
Fabian
I guess your may need to add this column to your schema, in order for SQL server to recognize it and take in under consideration in his optimizations.
I would have add a trigger that will update this column automaticly upon changes on your data.