Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am old school and new to MVC. I like the MVC that's more focus on action. But MS has bundled it w/ EF together, it's hard to not to use EF nowadays.
This is what I thought:
1 - RDBMS stored proc/package suppose have better performance over LINQ. For instance, SQL Server Transact-SQL supports paging now, compared with LINQ, TSQL definitely has better performance. So LINQ is only good for people don't know TSQL or PL/SQL in terms of performance.
2 - I've tried using LINQ w/ stored proc. Thought it works but has many limitation, for instance, .dbml files are strongly-typed, it prohibited any attempts of re-formatting the data, such as adding an anchor to a field of display. Well, one might say you're not supposed to do so. Let me give an example, business wants to make a column clickable in a grid. There are a number of ways to implement, one of the quickest is to embed an anchorto the column returned from a stored proc, very little change on the UI. Hence QA just needs to test a few. But using EF as the foundation, anything based on this model/class must QA again.
3 - Model-first or Code-first wouldn't get a nice normalized large-scale database implementation, this is because if a developer doesn't know TSQL he wouldn't be good at RDBMS design.
4 - This is the most important issue: in an enterprise environment, we developers can NOT dictate schema and table definitions. Even with DB-first approach, sometimes we don't even know where it comes from. But that's what EF is good about, right? You might say. Imagine EF detects all schema and what returned from stored proc, then builds all data-layer/class for me. Great, but there is a need for a real-time median price which is not in the database at all, we add it in w/ some customization code. It will be gone if another scan and detect is needed because our client requests something causes a tiny change in the database. How do we avoid this hassle of losing customization code?
5 - Sometimes we need to run "update-database" command in the package console so EF can work. It's almost impossible to explain to Operation and DBA that they are harmless during release.
However, as EF is getting popular there must be a new-school way to make it work. Can some experts educate old-school please?
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've done a lot of research into which architectural database approach is the best, and in the end, I'd prefer the separate database approach. However, most hosting providers are not happy with this (take Azure, with a 150 DB limitation).
My idea now, is to just start with a single database/single schema, use a tenant ID in each column to separate data, and then when it gets too big/slow, look for scaling options.
Is this a bad idea? Should I keep data separated from the start? I feel like security wise it doesn't matter much as long as I verify that the data i'm calling/retrieving belongs to the calling customer.
Also, isn't scaling later on going to be easier with a single big database, as oppposed to having 5000 small databases?
Thanks!
For cloud hosting I think a single multi tenant database is the way to go.
I had the same problem some times ago and opted for one database per tenant since our clients wanted to keep the option of hosting the database on their server. Since we had one code base and many databases on several servers, we had to roll a synchronizing solution to insure that all the schema stayed the same.
We also had some business logic in stored procedures and had to figure a way to distinguish the procedures that had global logic from those that had a logic specific to this database.
it worked but it was awkward and I wish we could have used a single database
Anyway, like said before each way has pluses and minuses, you just have to decide what is the most important to you and work around the minuses
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What's the diference between using relational database and relational database-object(hybrid).
Im making an application of adverts. Using common relational database, i think I could make tables of each type of adverts: cars,technology,estates,employment, services, this is the way a I do it.But reading about relational database-object I found that you can create a type field in the database(Oracle) that allows you to encapsulate another fields and methods, so what if I make only a table of adverts, knowing that all adverts have fields in common like title, description,the date it publish, images, but I can add a field that encapsulate another objects that will be cars,technology, employment, and inside of each one encapsulate attributes to them like
cars(model,brand,price),
technology(state,price,accesories,dimensions)
emloyment(job,payment)
Well this is the idea, actually for every advert you can actually enlarged the functionality, making a database for each one.
My question is: what are the potencial problems using relational database-object?
What is the best option?
Most if not all, of the worst database designs of the last ten years have at their root tables built to an object model rather than fitted to a relational model.
OOP is a programming thang; its concept of combining behaviour and data together works well when building APIs, etc. But it sucks when it comes to persistence, leading to horribly large tables, lots of duplicated data and monstrously slow queries. I'm not saying that's inevitable but it is the way to bet.
So why does Oracle support Types in the database? Because there are advantages to defining complex data types with behaviour: XMLType is one such, and Oracle Spatial makes extensive use of objects. But these usages are limited to individual columns of regular relational tables. The intention is not, and never has been, that we use object tables to store all the data in the database.
By all means use Types in your Pl/SQL programming. I have done this extensively, and for the right use case they can be extremely effective. Just don't store your data in them.
The most significant difference is that Oracle's object-relational technology is rarely used.
Very few programmers or DBAs have significant experience with object-relational technology. Database tools do not support objects well, or at all. Oracle does not support the technology well - it's buggy and does not get updated frequently.
Of course, just because a feature is rare does not mean you should ignore it. There are cases where Oracle's object-relational features work very well. But if you're planing to build a significant part of your database using objects, you need to consider the loss of skills, technology, and support.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
There is so much conflicting and confusing advice all over the web about this. And I would like to settle this for myself and for any one who will be looking for such information in future.
Question is — Will Entity frame work work well with database that has tables with no Primary keys.
Detail : I have a database and it has lots of tables that don't have a PK specified. Call it bad design or whatever, but there is nothing I could do to change the schema now. I have to work with it. And we would like to use EF because we like MS and we work with MS tools all the time. We sleep much easier knowing MS will keep updating and supporting this EF, with its full attention in future. Okay here now is my burning question which I have researched excessively on this website and others. "Can I use EF in my project fully knowing that my DB has some tables that will never have PKs" . Part of the problem is we really want to use EF for ease of use and we being MSphiles.
I have heard lot of advice ranging from:
It wont work.
It can be made to work.
Not a big deal at all...
That's where it gets really sick. Please advise.
Well, it largely depends on how you intend to use it. Without a primary key, you can't have referential integrity. So, in effect you can't have automatic lookups of subtables and such.
You can do manual joins of tables, and that should work.. but that severely limits the functionality of EF.
But here's the thing, nothing we say can convince you. What will convince you is doing it yourself. Build a test database, and a test app. Setup your EF database. See if it works for you.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
a colleague of mine uses Excel to merge and analyse datasets (~10k lines).
Her spreadsheets are mazes of vlookup and nested if formulas.
How can I convince her to take a look at databases?
What would be a good way to start? I'm an sqlite fan, but wonder whether the entry threshold to Access is lower?
Are there any books that you'd recommend to get started? I checked this SO question What's a good book for introduction to databases for web developers - any additions to the list there?
Thanks,
Simone
re: How can I convince her to take a look at databases?
show her why your way is better.
redo what she did in Excel with your preferred tool and the same input data and see if you can find differences in the output.
Also, after both systems are set up, run them side-by-side for awhile noting performance and maintenance differences. If she agrees your way is better, she might decide to use it.
Not a direct answer to your question but as a developer who has done extensive work on data analysis in Excel a few observations.
If the primary goal is data analysis then using Excel might be good enough.
Specially if the different data sets (you mentioned merging) are provided as csv files - as and when required - going through the 'hassle' of first importing data into a sql database and then running queries to extract data for the analysis step might be too much.
Excel gives you the flexibility of playing around with your data, very easily trying different things, charting, pivot tables etc. If the reports that your friend needs are more or less static with only the data varying, then maybe a simple Access/SQL database with a small application on top would be a better solution. But then again, if this is the case, your friend probably has an Excel sheet with all the relevant formulas where only the data needs to be plugged in.
For most of my data-analysis in Excel the only real thing I have missed is the ability to gather data using foreign keys. Once you have that covered with vlookup, the rest of the analysis is usually quicker/easier in Excel.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
How, if you have a database per client of a web application instead of one database used by all clients, do you go about providing updates and enhancements to all databases efficiently?
How do you roll out changes to schema and code in such a scenario?
It's kinda difficult for us. We have a custom program that writes a lot of the sql code for the different databases for us. Essentially it writes the code once and then copies it over and over again along with placing the change database commands etc. It also makes sure that the primary key identities etc are in sync when they need to be. Beyond that I would look at Red Gate's products. They have saved us more than once here. With them you can easily compare the dbs and see what is differnt. A must when dealing with multiple copies.
Use a code generator / scripting language to implement the original schema and updates to it over time.
I've used Red Gate's SQL Packager for this in the past. The beauty of this tool is that it creates a C# project for you that actually does the work so if you need to you can extend the functionality of the default package to do other things like insert default values into new columns that have been added to the db etc. In the end you have a nice tool that you can hand to a technician and all they have to do to upgrade multiple DBs is point it to the database and click a button.
Red Gate also has a product called SQL multi-script that allows you to run scripts against multiple servers/dbs at the same time. I've never used this tool but I imagine if you're looking for something to use internally that doesn't need to be packaged up you'd want to look at that.