Tag Info

New answers tagged

0

You could split your cache implementation into 2 parts, a Cache and a CacheStorage. The CacheStorage is only responsible for storing the cached data, and has a Singleton lifetime. Because it may be accessed by multiple threads concurrently, it should be thread-safe. The Cache is the dynamic part of the caching mechanism, it has a PerRequest lifecycle and ...


0

I would recommend looking at your SQL log to see what is getting executed. Also try the free 'newrelic' http://newrelic.com/ruby to help out with a detailed breakdown of performance. The problem will be that it's difficult to change when/how various queries are being executed when you call ActiveRecord associations so freely as you are now. Also, you're ...


0

In practice, it is difficult to release a new database version. While it is nice to have a module with the current DDL, in many cases you will likely be modifying an existing database. I would keep it as a separate module. The practice for DDL that I use, is to generate an upgrade (and downgrade) script for each release. Changes that break the current ...


0

I'm familiar with storing DDL scripts in repositories that use an ORM (i.e. ruby on rails). When I've seen DML mixed in with the DML's the results I have seen is: You can set up a database from scratch using them but you lose the ability to easily go back and forwards for individual steps.


0

I think you are on the right track with the EF stored procedures support. I would disagree with your pov about it would be pain to create stored proc and views. Views: One View per table Stored procedures: You will need at most three stored procedures Create Update Delete And most of it is boiler plate code. If the database is too big try using some ...


3

It depends on ones background and preferences. Some people came up using stored procedures and are very comfortable with them. They love T-SQL and can do a lot with it. They tend to write the SPs first and then use a minimal wrapper to use the SP. Note some people prefer their SPs a lot of the logic such as validation, business rules, data ...


0

You should use Repository pattern (domain driven design) that is decoupling business logic from infrastructure. Details (implementation) should depend upon abstraction, not other way. Repository pattern let you change underlying persistence storage (database) whenever you want, even in runtime and makes code much easier to test.


1

Since access to the data storage will not be concurrent and given only the "monitoring" program will write to it (according to your answers to some comments), my recommendation is: The safe way to go now seems to be a database, but you shouldn't be concerned right now with the administration of one Use SQLite locally in the machine the monitor runs in, ...



Top 50 recent answers are included