I am currently using C# / .NET and SQLLite to create Information System. The database will consist of one table with 95 columns of user information. Is it advisable to just put all the data into 1 table? Or what should be a best practice to have a good database and in the future it will more manageable?
Thank you in advance.
If all the data for the User belongs together, then 95 columns could be the right approach. Put differently, your User table should reflect your User class (domain object). The main thing you should consider is whether the table is normalized. It should be broken up if it isn't.
Related
I have a multi tennant application which will use the SILO Model to save data (each tennant will get an own database).
Because tennant names could be redundand my database are with GUIDs: MyApp_[GUID].
Now I want to save simple but neccesary information for each database like a tennant name and 3 to 5 more informations.
Is there a simple way to write and get these data?
The only way I can think of is to create a special table for this with only 1 row - but it seems a bot of wasting.
If you're looking for a simpler solution than a table per database (and having to deal with the awkward constraint that it must have exactly one row), you could
use a custom configuration parameter. You can change them with ALTER DATABASE. The downside is that you can only store strings, and that the settings might be overridden per session.
use a COMMENT on the database. The downside is that you can only store a single string per databasebase; the advantage is that it is automatically shown in many lists of databases such as psql's \l+ command
add your own columns to the pg_database system table. You should not mess with that, so it's a spectacularly bad idea even if you knew what you were doing, but in a relational model it's the closest to what you were asking for so I'd mention it for completeness.
I don't really advocate any of these solutions, although they do what you were asking for there's probably a better solution to your actual problem. It might be as simple a table of databases, possibly with a foreign key to pg_database, in an extra database shared by all tenants.
This question is only for understanding purpose. This might be a noob question.
Assume that I have a tabular or document NoSQL database which do not support transactions. And I have a locations table/document which has an is_active column. A user can have multiple locations, but can have a SINGLE is_active:true location only. Now, if the user wants to
Change an is_active location, how do we handle it? As I need to set is_active false for 1 row and true for another
A use case where a user wants to create a new location for himself and set that location as is_active
How do I handle these logics without a transaction in a NoSQL? Do I need to model my tables in some other way?
Let's assume that:
I cannot use an SQL
I should not use transaction support provided by DBs like Mongo
NOTE: These might be a lot of assumptions and might not be real-world use cases. But I am just trying to understand HOW we should model NoSQL databases.
This is a typical data modelling question for nosql systems. I won't put here the whole theory, but these are links to check: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-relational-modeling.html and https://cassandra.apache.org/doc/latest/cassandra/data_modeling/index.html
The key take away is that you don't want to create a normalized version of SQL like db in a nosql system. In your particular case, you have to explore access patterns for reads and writes; and that will help you to define you data structures. For example, you may want to get rid of "locations" table and keep those as properties of users - this is almost classical use case in nosql world.
I have a database which contains a table of cellphones. Let's say that every cellphone has 10 fields. In order to fill or modify the table I will have several forms available for the user. However, I don't want the user to modify all 10 fields every time. I want him to just give information about 4 of the fields and the rest of them will be automatically filled or modified by a program. Does someone know how to do that? :)
While possible with triggers, macros, or other coding, it's generally bad database practice to have calculated fields or duplicate data stored in tables. Related data should be stored through relationships between tables and displayed in a query, not directly in the table.
So if, say, each store only sells a single color of phone, you would have the user enter only the store. You would have another table that showed the relationship between store name and phone color. Then when you wanted a list of users and their phone colors, you would write a query that looks at the table list of users and where they bought their phones and joins it to the list of stores and what colors they sell.
My advice has three tiers:
Almost certainly best - redesign your database to be more normalized, meaning use relationships between tables to prevent the need for duplicate data.
If you decide you need macros, a good resource for working with OpenOffice macros is Andrew Pitonyak's book OpenOffice Macros Explained (a free download from his website).
SQL Triggers are often a cleaner way of doing this (compared to macros) but are not supported by the old database engine that is the Base default. (Base itself only handles queries, forms, and reports. The tables are handled by separate software, which by default is an old version 1.8 of HyperSQL Database or HSQLDB that is "embedded" inside Base.) You would need to upgrade to a newer database software. Instructions on upgrading to HSQLDB 2.3 are in this thread: [Tutorial] Splitting an "embedded HSQL database"
I'm just exploring the whole NoSQL concept. I've been playing around with Amazons DynamoDB and I really like the concept. However that said I am not quite sure how the data should be separated. By this I mean should I create a new Table for related data features like you would in a relational database or do I use a single table to store all the applications data?
As an example, in a relational DB I might have a table called users and a table called users_details. I would then for example, create a 1:1 relationship between the two tables. With the NoSQL concept I could theoretically create two tables as well but it strikes me as more efficient to have all the data in a single table.
If that is the case then when do you stop? Is the idea to store all the application data for a given user in a single table?
First ask yourself: why did I separate the users from the user details in RDBMS in the first place.
On a more general note, when talking about NoSQL you really shouldn't look at relationships between tables. You shouldn't think about "joining" information from different tables but rather prepare your data in a way that can be retrieved optimally.
In the user/user_details scenario, put all information in a users table, and query what you want by specifying the attributes to get.
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.