I am building a website with large database, there's 6 types of data, so 6 forms to pass data to database.
Each form has unique parameters, and 4 of 6 forms have the same fields and the fields can contain multiple data: email, address and phone can be multiple on 4 forms.
For the first i wanted to created 4 different tables like: store_contacts, warehouse_contacts, delivery_contacts, etc. to keep different types separated.
so i would have 4 similar tables containing the same fields:
id, phone, email, address, store_id/delivery_id/etc
I have read that better practice to create one table containing them, table Contacts:
id, type, type_id, phone, email, address
from similar questions:
Two tables with same columns or one table with additional column?
https://softwareengineering.stackexchange.com/questions/302573/one-wide-table-or-multiple-themed-tables
https://dba.stackexchange.com/questions/46852/multiple-similar-tables-vs-one-master-table
But i'm not sure if tables will change later and new fields will be added for store only or only for delivery. and apart from contacts i have similar situation for other fields.
Would it be comfortable to make queries with type every time i need to pull data for certain type or when i need to delete them? Won't it get messy when a lot of rows will be inserted? And if a new field will be created for 'store', it is okay that others will contain NULL on that field?
Probably you should read a bit about Relational Entities or Object Orientation - inheritance, depending on the paradigm you are working.
For example, you can get aware about it in articles like this
Usually you should store contacts in a separate and exclusive entity, for a plenty of reasons. Sector-specific fields can be stored in each table, only if you are sure that there would be no use for them in another entities. For example: warehouse_contacts would have an imaginary employee id field to represent an employee in warehouse repsonsible for attending a given contact. Even though, proably the best practice would be to build a third table managing this information.
Nevertheless, if performance is an issue, I mean, if you have millions of records and dozens and dozens of simultaneous access in your website, maybe your Data Base would run faster in fewer tables, not so normalized. But this situation is quite improbable for most enterprises and users. Rather, this situation is kind a common practice in large-scale and legacy systems.
Good luck.
Related
I have two tables User And Roles, user has username and roles as one to many relationship. So, to insert new row is very easy using cascade, also for update is easy because I'm taking old roles and compare with new ones.
But my concern is what if it were another case where the list would contain a large number of elements and would this form affect on performance?. It is better to continue like this or to use another form.
I have a sticky problem that I can't figure out how to do anyway but manually. Maybe you all can help me find a formula that would do this automatically. Here's the set-up.
My organization is currently switching CRM databases, and instead of paying the new CRM for a data upload they have tasked me with uploading the new data. Ok, no big deal, I've done it before, and it's not the worst.
However, the big problem I discovered is that with one of the databases (Raisers Edge NXT) I had to export the whole database out in two sections - one of the constituents and one of the gifts assigned to the constituents. FOR SOME REASON they exported these lists with no unique ID common between them.
So for example - I have a constituent ID for a record in the constituent list and I have a gift record for that constituent but nothing shared between them other than a name, which unfortunately might not be enough for the new Everyaction system to recognize when doing auto-uploads. So my solution is to create a unique Import ID for this import and add a unique ID to every unique name across the consituent and gift record lists so I can run two imports - one of the constituent and then one of the gifts and assign the gifts to the constituents.
Here's the big question how can I assign both lists the same unique IDs without having to go through all 3-4 thousand records manually?
Here's some sample data:
Sample Data of Problem:
I would like to create a database based on the following reasoning:
I want to assign to each contact I have some tags for his abilities, for example, so there will be a column called "abilities". So I was thinking about creating a list of possible abilities (probably on a second sheet), lets say "play football", "cook", "ride a bike" and define that "Mike" can "play football.
For this to be useful I would also like to know how it is possible to be able to filter my contacts by ticking on the list of abilities I am looking for.
There are a couple of ways to tackle this.
1) Make a table that has contacts and abilities all together. This means that you will repeat the contact info if a person has multiple abilities. Each row will be the unique combination of contact + ability. If you want to limit the options for ability to specific choices, create your list of abilities and use data validation to create a drop-down list of these values in your abilities column.
2) Make 3 tables: 1-Contact, 2-Abilities, 3-Map of Contacts to Abilities (each row contains the unique identifier for a contact and the unique identifier for an ability). I'm not sure if you really intend to make a database or just something in Excel that works. If you can use PowerPivot, that would be a good solution without needing another application to create your db. Bring your 3 tables into PowerPivot. Create a relationship between table 3 and table 1. Create a relationship between table 3 and table 2.
I have two tables which both include a date field. Currently I have two portals, one for each table (occurrence).
Is it was possible to display the results of both of these in one portal, and sort by the date?
Technically a portal can only display records from one table. If you need to join two tables then you have to do this manually or change the design and use one table instead of two (since you want them in the same portal, then the tables are similar to some degree; maybe this similarity can go into its own table).
Sometimes developers use the so-called virtual table technique: they create a table with, say, a field with the record number and a bunch of calculated fields that pick their values from elsewhere, for example, from prefilled global variables. They create a portal to this table, set up the relationship to display the required number of records, and write the code to fill these variables. This way they can show data that isn't stored in any table, combine tables, etc. But it's an arcane technique, I would recommend it only as the last resort.
Each user of my system can have contacts. Each contact has details like Name, Address, Email, Phone, etc.
Do you think is a good idea to store this contacts in Azure Tables? I am worried about the following:
How do I search for a specific field (like Email or Phone)?
How do I get only the contacts belonging to a specific user?
How do I sort the contacts by a field?
I think that contacts could be a good candidate for storing in Table Storage - but only if you can partition on the owning person and never really need to search or aggregate across multiple owning users.
One possible design for this is:
store the contacts once with the owning user as partition key and some unique field for row key, but with the fields as columns within each row.
How do I search for a specific field (like Email or Phone)?
You can then ask table storage to search within a partition - it will then do a scan within that partition - which shouldn't be particularly large or slow for any single partition.
How do I get only the contacts belonging to a specific user?
This is just a simple query by partition key only
How do I sort the contacts by a field?
All results from table storage are sorted by (partitionkey, rowkey) so to sort the contacts for a user, you'll need to query for all of them, and then sort them within your web or worker role.
Other designs are, of course, possible -
e.g. you could store each contact in multiple rows in multiple tables - this would then allow you to have pre-formed sort orders within the table storage.
e.g. you could use separate tables instead of separate partitionkeys for each user - this has the advantage that when you delete a user, you can delete the entire table belonging to that user.
Note... while it's possible to use table storage for this... actually I almost always seem to end up back in SQL Azure at the moment - it's just so much more powerful and predictable (IMO). When the team deliver secondary indexing, then I might be tempted to use it for more of my data.