We are working on SLI Search module for our client. I want to ask you is that a good approach to make separate tables or should I manage all clients data into single table?
Keep in mind that user can ask to update their module, means that table structure can be different of each client.
Secondly, client will give me their data and I will update all clients data in their tables or in single table using Package.
So, it will be good approach to make their separate tables in database or should i make a centralized table for all our clients?
If the table field varies from client (customer) to client, then it is recommended to have separate tables otherwise you will create a lot of null records.
Secondly, if every client is a separate instance and there is no correlation between them, then why now have a separate schema or database for them?
Sounds like SQLite database will be a good fit as every client data structure is unique, so you better make it portable so you can amend one SQLite database at a time.
Centralised Tables Approach
There is a new study and research that we used recently but you need to consider indexing issue for fast search on the fields.
Anyway, you can create a flat table, which have have many columns with sequential numbers e.g. Field1, Field2, Field3, Field4.....Field99, Field100... Field150 (as many potential customer fields you have).
You create another table and in that you map labels for every client (customer) to these fields. E.g.
Client ABC id is 10032
He has used from Field1 to Field11
Field1 has a label name FirstName
Field2 label is Surname
Field3 label is DOB
...
...
Field11 label is UserCountry
Now every time records are shown, you fetch the logged user labels and then map them to fields.
I hope this answers the question.
Related
I'm creating a rather large APEX application which allows managers to go in and record statistics for associates in the company. Currently we have a database in oracle with data from AD which hold all the associates information. Name, Manager, Employee ID, etc.
Now I'm responsible for creating and modeling a table that will house all their stats for each employee. The table I have created has over 90+ columns in it. Some contain data such as:
Documents Processed
Calls Received
Amount of Doc 1 Processed
Amount of Doc 2 Processed
and the list goes on for well over 90 attributes. So here is my question:
When creating this table in my application with so many different columns how would I go about choosing a primary key that's appropriate? Should I link it to our employee table using the employees identification which is unique (each have a associate number)?
Secondly, how can I create these tables (and possibly form) to allow me to associate the statistic I am entering for an individual to the actual individual?
I have ordered two books from amazon on data modeling since I am new to APEX and DBA design. Not a fresh chicken, but new enough to need some guidance. An additional problem I am running into is that each form can have only 60 fields to it. So I had thought about creating tables for different functions out of my 90+ I have.
Thanks
4.2 allows for 200 items per page.
oracle apex component limits
A couple of questions come to mind:
Are you sure that the employee Ids are not recyclable? If these ids are unique and not recycled.. you've found yourself a good primary key.
What do you plan on doing when you decide to add a new metric? Seems like you might have to add a new column to your rather large and likely not normalized table.
I'd recommend a vertical table for your metrics.. you can use oracle's pivot function to make your data appear more like a horizontal table.
If you went this route you would store your employee Id in one column, your metric key in another, and value...
I'd recommend that you create a metric table consisting of a primary key, a metric label, an active indicator, creation timestamp, creation user id, modified timestamp, modified user id.
This metric table will allow you to add new metrics, change the name of the metric, deactivate a metric, and determine who changed what and when.
This would be a much more flexible approach in my opinion. You may also want to think about audit logs.
I am looking for the best way to setup my SQL tables in the following scenario.
I will do my best to explain my situation.
For instance, I have 10 tests, Test1, Test2, Test3, ...., Test10. They all use similar field but some tests will use different fields depending on the test.
Let's say Test1 uses Field1,Field2, Field3. Test2 uses Field1, Field2, Field4, Field5. I need to store the required field information into a table, but I also need to store what fields each tests use. I will be accessing this info using VB.net.
I am looking for the best way to set this up. It needs to be somewhat easy to maintain but also have pretty good performance.
My initial thought was to setup two tables. One table the would store each test results and one that would store the fields used for each test.
The one that would store each test results would have every possible column any of the tests could use. The table for which fields each test would use would also have all possible columns. In this instance, each row would be a test and each column would be which fields are used for that test. So, Test1 would have a 1 in Column1, Column2, and Column3. Test2 would have a 1 in Column1, Column2, Column4, and Column5. This would tell us what fields need to be used when selecting, Updating, or Inserting into our results table.
Hopefully that makes sense on what I am trying to accomplish. I am not sure if this is the best way to accomplish my requirements or not.
Any guidance here would be greatly appreciated.
Thanks,
Tony
UPDATE
I just want to clarify that I am using MS SQL.
UPDATE
I also wanted to clarify that my field names aren't actually Field 1, Field2, etc. I am just using that to try and explain what I am trying to accomplish.
What you are asking for I believe, is a variable column table. Especially if you consider the long-term affects of adding more tests.
One thing for certain, the way NOT to solve the problem is to add a bunch of columns with generic names (field1, 2, 3 .... 40) and use them as you need in hopes that you never need 40. This makes for a design that is highly problematic to develop around and maintain.
A less horrible approach but still problematic is to make a table that pivots fields and makes them each their own row, and associates the two.
A better solution, using modern databases, is to store your objects (tests) in a no-schema type of way. In a relational database that supports it, you can use a native XML field (or json in some databases). In this scenario, you store the meta data about the object in regular fields and store the XML-serialized objects in the xml field. This way, your object can change as needed without a change to the database schema and you can continue to use meaningful names and data types.
It is important in the relational db scenario to choose a db that has a native xml or json datatype, vs. just using a varchar or blob. The reason is that a native type will include the ability to query the data in ways that are generally more performant than regex.
Of course, this what no-sql databases such as MongoDB are great at. I've had good success with both approaches. For simple solutions, I'll generally choose Mongo. For solutions in which I need a relational database anyway, I'll use MS-SQL and SQLXml.
SteveJ
You need four tables. Tests and Fields have a many-to-many relationship, so you need these two tables plus a TestsFields junction table. Finally you need a results table with TestNumber, Fieldnumber and Result fields. This fits the information given in your question, though it's a little ambiguous. You might need to extend this schema to accomodate multiple testsessions/exams, or whatever - you've not given this context so I can't say.
EDIT:
For instance, lets take a car servicing app as an example.
(Unfortunately you've chosen 'Fields' for one of your tables, and I want to use 'fields' in what follows, so I've distinguished them by capitalisation) In this scenario, Tests table would have the fields TestID and Description, with values like 1, 'Pre-delivery Inspection', 2, '5000 mile service' etc and Fields table would have fieldID and Description, with values like 1, 'Check tyre pressure' , 2, 'Check Handbrake cable' etc.
Then the junction table TestsFields would just consist of the two primary keys.
In this scenario, you would also need another table or two to cover the individual cars, service appointments etc, but let's not get carried away!
The results table would include ServiceApptID,TestID, FieldID, and Result. Result could be free text, where the mechanic could record results, or another lookup to a set of canned responses - 1 'Adjusted', 2, 'Part Replaced' etc
Should be enough there to get the idea across.
I think the better way is use custom char as separator for example | char
like this
somthing|another field|another filed data
when you want to read data split by |
and also you can save selected value by this scenario
1|3|5|2|0|4|1|2
you need only 2 string field to store question and answer :)
I'm designing a database that has a couple of tables; FAQ's, Bulletins, and Attachments. Bulletins and FAQ's could have an attachment associated with them, so my initial thought was to create a joining table with the two primary keys as a composite key:
Bulletin
--------
BulletinID
Subject
Description
Notes
Attachment
-----------
AttachmentID
FileName
FilePath
etc.
Joining table:
BulletinAttachments
-------------------
BulletinID
AttachmentID
As I design this, I also thought, what if other entities are introduced later (say Newsletter, Email, etc.) that need Attachments as well. I would have to create a joining table for each of these entities. Not awful, but it made me think, what if I got rid of the joining tables and put an AttachmentType in the Attachment table and then assigned the type accordingly:
AttachmentType
--------------
AttachmentTypeID
AttachmentType
Description
The data in that table would be:
1-Bulletin
2-FAQ
3-Newsletter
4-Email
Then the Attachment table would hold the AttachmentTypeID to identify it:
Attachments
-----------
AttachmentID
AttachmentTypeID
FileName
FilePath
etc.
So my question is, for performance wise (using SQL 2008 R2), is there a better choice between the two? Is there a better way to design this? My concern with using individual joining tables is that we may have more entities come along and to accommodate Attachments, we would have to create a joining table and on our front-end software, we would have to write logic for it whereas the AttachmentTypeID would allow the front-end to insert a new AttachmentType and no db interaction would be needed.
Your second solution doesn't have a way to link the attachment to the item, just what kind of item it is.
Even if it did (ie: an itemID), what you would create would be a violation of 4th Normal form - ie: a multivalued dependency.
Stick with your first plan, but consider whether Bulletins are fundamentally different to Newsletters, Emails, FAQs, etc in your application. If you do need a new table for Newsletters, add a new table for NewsletterAttachments.
Also consider, are you going to share attachments between different items, or types of item?
I am totally agree with podiluska. you need to create separate table for each type of attachment otherwise you cant map itemid with attachment and you will face a problem of joining table for different type of attachment . also if you make separate table for each type of attachment then performance will be faster .
This question may answer itself, but it is also a question of best practices.
I am designing an application that allows users (comapnies) to create an account. Those users are placed in a table "Shop_table". Now each shop has dynamic data, however the tables would be the same for each shop, like shop_employees, shop_info, shop_data.
Would it be more effective to have a specific table for each shop or would I just link their data by the shop id.
For example:
shop: Dunkins with id:1
shop: Starbucks with id:2
would dunkins have its own dunkins_shop_employees, dunkins_shop_info, dunkins_shop_data tables
and Starbucks have its own starbucks_shop_employees , starbucks_shop_info , starbucks_shop_data
or would i have one table shope_employees, shop_info, shop_data and link by id 1 or 2, etc..
Definitely one table for each entity with a field to identify the company.
If all the companies have the same information there is no need to create tables for each, and if you did your queries will become a nightmare.
Do you really want a load of UNION queries in order to get any aggregate data across companies? You will also have to modify all queries in your DB as soon as another company (and therefore multiple tables) are added.
Define your tables independently, model the entities you want to store and dont think about who they belong to.
You should have only one table ( for each shop_info etc.. )
Creating similar tables is a maintenance nightmare. You will need to create similar foreign keys, similar constraints, similar indexes, etc.
If your concern is privacy, this should be controlled in your application. You application should always add a "WHERE" clause based on who is logged in/ querying.
If you absolutely need to - you can create views which where clause as shop_id. You can give rights to various people on the view only. This would only make sense if you had a big customer who wanted some SQL level query ability.
I am working with database tables that contains PII and sensitive information. Some of the data is PII and company sensitive information. The design document may not always be available to the developer especially when the data is being exposed by a view outside of the database (Oracle database link) to another program.
Is there good naming conventions for letting the developers know the column contains PII or sensitive information?
Column names? Weak.
Use a table of PII data that contains all of the PII attributes. Keep the PII tables separate from other tables with non-PII.
A one-to-one join between the non-PII and PII isn't all that costly. And it provides clear, obvious use of the PII table and PII columns.
I agree with S.Lott but I'll be more explicit. If the data are sensitive then it's even MORE important that column names be chosen to mean what they actually contain, that datatypes be actually appropriate for the contents; and the constraints actually match the problem domain.
Then, on top of that, move this stuff to another table, where they can be appropriately encrypted, stored in the correct location, etc.
I would have separate views (eg table PERSON with PERSON_BASIC having no PII columns and PERSON_PII with the PII columns). That way, if it is later decided that a column is sensitive (eg Date of Birth), then you can easily recreate the views to remove the column from the basic view rather than some massive data restructuring exercise which you would get with separate tables.
Also, the optimizer is getting better at correlation between columns on the same table (and you'd expect that to improve over time). Once you start joining non-PII tables to PII tables, you've just made it more complicated.
If you do go for separate tables, and think they'll need to be joined often, look into clusters so that the records for the same person are on the same block.
Consider using a role secured by a password or through a package to control access to the PII view/columns.
CONTEXT can do this too. They are forced to call the package to set the context before they see the columns.
The view could be
SELECT name, date_of_birth,
case when SYS_CONTEXT('SEC','xxx') ='ALLOW' THEN ssn END
from ...