I have a public synonym on my server for transactions: However I'd like to be able to work with my own local version of the table, so as not to disturb other users.
Does Oracle's SQL resolve naming conflicts like this in a predictable fashion?
In other words, if another user creates a public synonym called TRANSACTION and I do this:
CREATE TABLE TRANSACTION (
ID NUMBER
);
When I write
select * from TRANSACTION
Do I have any guarantee that Oracle will always resolve the synonym or my local table?
(I know I could technically specify schema.TRANSACTION to force the issue, but in my case that would require me to modify/rebuild an application and I'm hoping to save some work.)
Your understanding of name resolution is correct. Oracle will first look in the current schema to find an object with that name. So, In case of a conflict, It will choose an object in the current schema instead of the object referred to by the public synonym.
http://docs.oracle.com/cd/B28359_01/server.111/b28310/general008.htm
Oracle Database attempts to qualify the first piece of the name
referenced in the SQL statement. For example, in scott.emp, scott is
the first piece. If there is only one piece, the one piece is
considered the first piece.
In the current schema, the database searches for an object whose name
matches the first piece of the object name. If it does not find such
an object, it continues with step b.
The database searches for a public synonym that matches the first
piece of the name. If it does not find one, it continues with step c.
The database searches for a schema whose name matches the first piece
of the object name. If it finds one, it returns to step b, now using
the second piece of the name as the object to find in the qualified
schema. If the second piece does not correspond to an object in the
previously qualified schema or there is not a second piece, the
database returns an error.
If no schema is found in step c, the object cannot be qualified and
the database returns an error.
Having said that, this is one of the problems with public synonyms. Having objects like this will lead to confusion down the road, both for development and support. You are better off referencing the object by owner and name in both cases
Related
I'm trying to model the following relationships between entities, mainly consisting of a partial, disjoint generalization.
original EERD
'mapped' to relational
Since I didn't need the subclasses to have any particular attributes I decided to use the "single table inheritance" approach, added the "type" field and moved the relationships towards the parent.
After that I had two choices to make:
1- type for the "business type" attribute
2- way to constraint participation to at most one of the 4 relationships based on the type attribute
For the sake of portability and extensibility I decided to implement no.1 as a lookup table (rather than enum or a hardcoded check).
About no.2 I figured the best way to enforce participation and exclusivity constraints on the four relationships would be a trigger.
The problem is that now I'm not really sure how to write a trigger function; for instance it would have to reference values inserted into business type, so I'd have to make sure those can't be changed or deleted in the future.
I feel like I'm doing something wrong so I wanted to ask for feedback before going further; is this a suitable approach in your opinion?
I found an interesting article describing a possible solution: it feels a bit like an 'hack' but it should be working
(it's intended for SQL Server, but it can be easily applied in postgres too).
EDIT:
It consists in adding a type field to the parent table, and then have every child table reference said field along with the parent's id by using a foreign key constraint (a UNIQUE constraint on this pair of fields has to be added beforehand, since FKs must be unique).
Now in order to force the type field to match the table it belongs to, one adds a check constraint/always generated value ensuring that the type column always has the same value
(eg: CHECK(Business_type_id = 1) in the Husbandry table, where 1 represents 'husbandry' in the type lookup table).
The only issue is that it requires a whole column in every subclass, each containing the same generated value repeated over and over (waste of space?), and it may fall apart as soon as the IDs in the lookup table are modified
I want to know the best way of avoiding entity duplication in an ASP.NET Core Web API project.
Imagine that you have a product with a name and manufacturer and you want to make sure if the name is not duplicated. Imagine that a new product with a name came from client (dto) and we need to look if the name (entity) already exists in the database (using EF).
You need to trim the name (name.trim()) for both names from entity and dto
You need to remove all the whitespaces in between (string.replace(" ", string.empty())
You need to change everything to lower case (string.lower())
Finally you need to compare these two
Is there any best practices how to do this without writing all the code? I tried to use string.compare with the compareoptions like ignorecase and ignoresymbols and also the string.equal() with ignorecase option but the EF gives me an alarm that it can not translate the code.
br
I have a suggestion for your approach.
Introduce another column (This can be a primary key with other keys) and save the name with trimming and lowercase when you insert a new record to that table.
Example:
Original Name : Amir Masoud Babaei -->
New Column value: amirmasoudbabaei
And when you insert a new record, do your trimming and lowercase changes and save it to the database. Since it is a primary key, it should throw an error.
So with this approach, you don't need to loop through all the names and validate if the name is already exist.
I am using go and pq to interface with my postgres database.
I have a simple user table which has basic fields. Id, name, type. My auxillary table, admin inherits from user and adds it's own field panel, and another one that is owner and adds owner. Whether that be using table inheritance, or a supporting table.
My question is if I hit and endpoint that points to user/1 at this point I don't know what type of user this person is yet here. I know we can use jwts and other ways to provide this from the front end. I'm more curious about if there is a way to figure out the user and it's type and query the additional fields in one query?
Ie. I hit the endpoint I would Select from users, get the type, then use that type to get the additional fields. So I would effectively be doing two queries on two tables to get the complete data. Is there a better solution of doing this? Is there some optimizations I could do.
I have a legacy database with a particular table -- I will call it ItemTable -- that can have billions of rows of data. To overcome database restrictions, we have decided to split the table into "silos" whenever the number of rows reaches 100,000,000. So, ItemTable will exist, then a procedure will run in the middle of the night to check the number of rows. If numberOfRows is > 100,000,000 then silo1_ItemTable will be created. Any Items added to the database from now on will be added to silo1_ItemTable (until it grows to big, then silo2_ItemTable will exist...)
ItemTable and silo1_ItemTable can be mapped to the same Item entity because the table structures are identical, but I am not sure how to set this mapping up at runtime, or how to specify the table name for my queries. All inserts should be added to the latest siloX_ItemTable, and all Reads should be from a specified siloX_ItemTable.
I have a separate siloTracker table that will give me the table name to insert/read the data from, but I am not sure how I can use this with entity framework...
Thoughts?
You could try to use the Entity Inheritance to get this. So you have a base class which has all the fields mapped to ItemTable and then you have descendant classes that inherit from ItemTable entity and is mapped to the silo tables in the db. Every time you create a new silo you create a new entity mapped to that silo table.
[Table("ItemTable")]
public class Item
{
//All the fields in the table goes here
}
[Table("silo1_ItemTable")]
public class Silo1Item : Item
{
}
[Table("silo2_ItemTable")]
public class Silo2Item : Item
{
}
You can find more information on this here
Other option is to create a view that creates a union of all those table and map your entity to that view.
As mentioned in my comment, to solve this problem I am using the SQLQuery method that is exposed by DBSet. Since all my item tables have the exact same schema, I can use the SQLQuery to define my own query and I can pass in the name of the table to the query. Tested on my system and it is working well.
See this link for an explanation of running raw queries with entity framework:
EF raw query documentation
If anyone has a better way to solve my question, please leave a comment.
[UPDATE]
I agree that stored procedures are also a great option, but for some reason my management is very resistant to make any changes to our database. It is easier for me (and our customers) to put the sql in code and acknowledge the fact that there is raw sql. At least I can hide it from the other layers rather easily.
[/UPDATE]
Possible solution for this problem may be using context initialization with DbCompiledModel param:
var builder = new DbModelBuilder(DbModelBuilderVersion.V6_0);
builder.Configurations.Add(new EntityTypeConfiguration<EntityName>());
builder.Entity<EntityName>().ToTable("TableNameDefinedInRuntime");
var dynamicContext = new MyDbContext(builder.Build(context.Database.Connection).Compile());
For some reason in EF6 it fails on second table request, but mapping inside context looks correct on the moment of execution.
Say my object has a Name field, and I wish to split it into FirstName and LastName fields. Or maybe it has an address string and I'm adding Lat and Lng fields that require geocoding. Etc etc.
I expected to have access to my DbContext in the Up() and Down() methods, but all I've been able to find (besides the builtin functions) is the .Sql() call. This is enough for adding and removing columns, but not for transforming existing data into new formats.
Is it safe to reference my DbContext inside an Up() invocation? Or is there another recommended pattern for implement migrations that require more than trivial SQL?
No you cannot use DbContext inside Up method because it already refers new model but your database still targets the old model.
Edit:
All data migrations must be done through Sql. You can for example create temporary table, move old data to temporary table, use migration of table structure and move data from temporary table back to the original with using some transformation directly in SQL - splitting varchar values should not be a big deal.
Rather than trying to split the Name into two different fields, rethink your migration. Sometimes it might be best staged. I can think of two ways to perform your transformation.
Migration path #1: New Fields, then Delete old
Create migration for new field for FirstName and LastName, and in the Up() method, you still have the Name field, split it, insert into First and Last fields.
Create another migration to remove the old Name field.
Migration path #2: Repurpose and Rename
Create a migration adding the LastName field, and renaming Name to FirstName, move the last name data, modify the renamed First/Name field to only hold the first name.
Both paths have advantages and disadvantages. And regardless of the complexity of your transformation, you should be able to break it out into logical stages to accomplish the goal.