How to create multiple tables for an entity?
It's impossible in greenDAO, and there are no plans to support this feature at this time. Could you explain why you want to do that and how this should work? Maybe there are better ways...
Related
I am initiating a new project which will be available as a SaaS for multiple customers. So, I am thinking of creating a database and then create individual schema for every customer.
I have defined some rules and the first rule is all the customers must always have the same schema. No matter what. If one customer gets an update, all the other customers will get the update as well.
For this purpose, my question is, is it possible to inherit schema from another schema in the same database? If not, do I have to manually create all the tables and indexes in the new schema and inherit them from the tables in master schema?
I am using Postgresql 9.6 but I can upgrade it as well if needed.
I open to suggestions.
Thanks in advance
There is no automated way to establish inheritance between all tables in two schemas, you'd have to do it one by one (a function can help).
However, I invite you to stop and think about your data model for a bit. How many users do you expect? If there could be many, plan differently, because databases with thousands of schemas become unwieldy (e.g. catalog lookups will become slow).
You might be better off with one schema for all users. If you are concerned with separation of the data and security, row level security might be the solution for you.
I am curious to know that if Entity framework can create tables in other databases besides MS-SQL ??
Moreover, is there any provision to create XML schema through EF ?
Under the hood Entity Framework uses providers that are specific for different databases. So it depends on a provider whether EF can create tables or not. However, I haven't heard about providers that do not have this possibility. The easiest way to be sure is to write a simple program with a few lines of code.
As to XML schema. Are you asking about using XML files instead of database as the storage for your data? If so, again it depends on the provider. If you want you can theoretically create one that will use XML files. However, I haven't tried to do so and I don't think that it is a good idea. There are technologies that fit here better (see this question).
I have some tables which should add to my database every year and name of databases contains the year (like sell2005) and iv'e written some ef queries on these tables ,and queries can only be on a single entity (like sell2005) but what should i do when sell2006 or sell2007 add ? how can i manage them with that single query which iv'e written before?
thank you.
There is no easy way. EF is simply not tool for this scenario. For EF you must have "single table" so you must either use partitioning with one real database table partitioned by year or you must build a view on top of these tables.
The problem is that in EF you have strict relation between classes and tables. You cannot have single class mapped to multiple tables even if they are exactly same (except inheritance which is not solution for you). So the workaround would require to have multiple SSDL/MSL mappings - one for each table and construct correct context instance with correct mapping for every query. As I know dynamic changes of mapping are not possible (except modifying SSDL/MSL files before using them).
in T-SQL (SQL Server 2008), is it technically correct to INNER JOIN two tables through key-less columns (no relationships)? Thank you.
Yes. I often join child of a child table bypassing the "middle" table.
Foreign keys are constraint for data integrity: nothing to do with query formulation. You should have them anyway unless you don't care about data quality and integrity.
You can join on any two fields that have the same data (and they should be the same datatype as well). If the fields are indexed you should not have performance issues either unless you are joining on two varchar (4000) fields. You may even need to do this when you have a poor database design and one column is serving more than one purpose espcially if you have used an EAV model.
However what you won't get in this scenario is data integrity. Without a foreign key to enforce the rules, you may find that the related table has values that don't have a match to the parent table. This could result in records not seen in queries that should be seen or records which cannot be correctly interpreted. So it is a good practice to set up foreign keys where they are applicable.
It will work, it might not be very efficient though...You should definitely create the foreign keys if you can.
Technically it will work. No problems there.However, sometimes the query plan generator will use FK's to help make better use of indexes. But, from a design standpoint, it's not such a great idea. You should be using FK's as much as possible, especially if you want to go the ORM route.
I'm a newbie to pgsql. I have few questionss on it:
1) I know it is possible to access columns by <schema>.<table_name>, but when I try to access columns like <db_name>.<schema>.<table_name> it throwing error like
Cross-database references are not implemented
How do I implement it?
2) We have 10+ tables and 6 of have 2000+ rows. Is it fine to maintain all of them in one database? Or should I create dbs to maintain them?
3) From above questions tables which have over 2000+ rows, for a particular process I need a few rows of data. I have created views to get those rows.
For example: a table contains details of employees, they divide into 3 types; manager, architect, and engineer. Very obvious thing this table not getting each every process... process use to read data from it...
I think there are two ways to get data SELECT * FROM emp WHERE type='manager', or I can create views for manager, architect n engineer and get data SELECT * FROM view_manager
Can you suggest any better way to do this?
4) Do views also require storage space, like tables do?
Thanx in advance.
Cross Database exists in PostGreSQL for years now. You must prefix the name of the database by the database name (and, of course, have the right to query on it). You'll come with something like this:
SELECT alias_1.col1, alias_2.col3 FROM table_1 as alias_1, database_b.table_2 as alias_2 WHERE ...
If your database is on another instance, then you'll need to use the dblink contrib.
This question doe not make sens. Please refine.
Generally, views are use to simplify the writing of other queries that reuse them. In your case, as you describe it, maybe that stored proceudre would better fits you needs.
No, expect the view definition.
1: A workaround is to open a connection to the other database, and (if using psql(1)) set that as your current connection. However, this will work only if you don't try to join tables in both databases.
1) That means it's not a feature Postgres supports. I do not know any way to create a query that runs on more than one database.
2) That's fine for one database. Single databases can contains billions of rows.
3) Don't bother creating views, the queries are simple enough anyway.
4) Views don't require space in the database except their query definition.