I make use of Materialized View Pattern on one of the database tables. I append a new field to the table taken from another service via events. But the question is there any patterns for appending this new field to old data existed so far?
So I have a table:
CarService (CarId, ServiceId)
and I need to have there Car Name. So whenever I add a new car service row, I reach CarService to get a car name. On any update of car service, I subscribed for events from it and whenever it change I change name in CarService table
But I need to have populated rows existed before introducing Car Name. The only idea I have is to loop through all CarService table rows and reach CarService to get Car name. Which I don't like really.
Is there any best practices on how to do it more easily and error-prone?
Any help is appreciated.
Related
So im working on a side project involving the Steam API and I am not sure if this would be a suitable and effective way to do what I want.
Basically I have a User model with an inventory field relating to a certain game. I fetch the Users game inventory when they log-in and store the json result within this single field. I have another model which contains the item schema for every item in the game.
Basically I want to relate the information stored within the database for a particular item(item model) to that items information within the json result(inventory items).
I previously tried to save the inventory in a separate table and created a relation between the user, user-inventory and items in this table however the problem with this was ensuring that the inventory stored in my database was the same as that fetched (exactly identical). Under this scenario I would basically need to delete(multiples may exists of the same item) every inventory item and then insert the inventory items retrieved at login back in.
My question is this. Is this an appropriate solution, bad practice or is there a better way to do what i need?
Thanks
Are you sure that you have to delete all of the inventory items and re-add the new ones? Could you iterate through each of the inventory entries and add/update/delete as needed?
I think that the JSON solution would work. It's probably a matter of preference at this point. I always feel like it's nicer to stay with a traditional relational data structure until you really need to optimize. But I don't see why the json wouldn't work. You can create a utility function on your user model that extracts the item ids and fetches all of the related records.
I'm pretty new to yii.
I have a form that creates and saves multiple AR models to the database. The problem is that in many cases new entries are actually identical to existing ones. I would like to reduce/ eliminate this kind data redundancy.
The form has 3 entities:
- the main model
- client model
- product model
Many times, product and client will already exist in the database.
Product and Client are referenced through foreign keys in the main model.
I want to know how would it be possible to do the following:
as I type a client's name or phone number, yii searches in the client table and display results as suggestions, through ajax.
if I select one of the suggestions, the Client AR should be populated with that database entry.
when the form is submitted:
if an existing client was selected, use that client's id inside the main model. Do not create a duplicate client in the database.
if client wasn't found in the existing records, create a new one with the provided form data.
I apologize for the bad formatting, this is my second time posting a question. If I wasn't very clear in what I am looking for, please ask for clarification. This is something I would really like to learn.
I created a database that holds a STUDENT table, a COURSE table, and an intersection table named STUDENT_COURSE. However, I have problems with duplicated rows and I don't know how to solve them.
Here are pictures of the tables in design view and many-to-many relationship I have created.
http://imgur.com/P7DI1l&THH7A (Be sure to click the "Second Image" link to view the relationships picture.)
In an attempt to simplify data entry, I used the form wizard to set up a SCHEDULE form (and subform).
http://imgur.com/isf4Y&ARYu3
As you can see, one enters the student data in the form and the course data associated with that specific student in the subform. However, when one enters course subform data, it creates a new courseID (autoNumber). This new courseID results in duplicate courseNames (See "Linear Algebra" entries in above imgur link via "Second Image") so that associated students aren't grouped together when one queries by class.
Is there a flaw in my design? Am I not using the form correctly to enter data? Please help me troubleshoot this.
Thank you very much!
Your subform should be based on STUDENT_COURSE table and not on COURSE one. You can still add columns from COURSE table to the subform to display course related data.
Here are some links:
http://www.techrepublic.com/article/accommodating-a-many-to-many-relationship-in-access/5285168
http://www.dhdurso.org/articles/ms-access-forms-pg4.html
http://en.allexperts.com/q/Using-MS-Access-1440/Help-form.htm
I've designed a database structure where data is collected about cars over a period of time, for research purposes. The owner of the car enters a large amount of related data each month about the car, it's performance etc. However, I now have to handle situations where ownership of the car is transferred (possibly more than once), and I'm wondering what the best way to handle this in the database would be.
If a car is transferred, the previous owner should no longer be able to add data about the car, however they should still be able to view the data they entered up until the date of the transfer. The new owner will be able to enter data about the car from the date of the transfer onwards. For research purposes, I need to be able to join the data between these transferred car records and consolidate them into one set of data.
Currently, each car record in the db belongs to an owner via a foreign key in the Cars table. What I'm thinking about at the moment, is to create a recursive parent/child relationship between car records, where one car record may belong to another car record (e.g car_id as a foreign key in Car table). Where a car record belongs to another car record, this indicates a transfer. This allows me to preserve each car record's set of data (specific to its owner), while also chaining together the related car records. In addition to this, I'm thinking about adding a Car_transfer table, to record extra data about the transfer (probably just the date actually, as the previous and new owners will be evident from the owner_ids in the Car table) - adding a date_transferred column in the Car record would likely be largely redundant for most records, so i'm unsure if this data alone merits a new relationship table.
Anyway, i hope this makes sense! I've been going round in circles trying to find a sensible solution - any advice would be greatly appreciated!
You don't need recursive parent/child here, but just Many-To-Many relationship:
Basically you need links table [cars-owners]:
car_id, owner_id, ownership_date
So you will have data in it:
---------------
1, 2, 2009-01-01
1, 3, 2010-05-01
...
The same car owned by two people with different dates.
I would add a car ownership table. The recursive design isn't too intuitive.
Say you have a ServiceCall database table that records down all the service calls made to you. Each of this record contains a many to one relationship to Customer record, where it stores which customer made the Service Call.
Ok, suppose the Customer has stop doing business with you and you do not need the Customer's record in your database. No longer need the Customer's name to appear in the dropdown list when you create a new ServiceCall record.
What do you do?
Do you allow the user to delete the Customer's record from the database?
Do you set a special column IsDeleted to true for that Customer's record, then make sure all dropdown list will not load all records that has IsDeleted set to true? Although this keeps the old records from breaking at innerjoins, it also prevents user from adding a new record with the same name as the old Customer, won't it?
Do you disallow deletion at all? Just allow to 'disable' it?
Any other strategies you used? I am guessing everyone have their way, I just need to see your opinions.
Of course the above is quite simplified, usually a ServiceCall record will link to many other entity tables. All of which will face the same problem when they are required to be deleted.
I prefer to set an IsDeleted flag, one of the benefits is you can still report on historical information (all teh data is still there).
As to the issue of not being able to insert another customer with the same name, this isn't a problem if you use an ID column (eg CustomerId) which is generally auto populated.
I agree with #Tetraneutron's answer.
Additionally, you can create a VIEW that lists only the active customers, to make it more convenient to populate drop-down lists and such.