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.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
Is there a way to prevent reverse engineering an SSAS (SQL Server Analysis Services) database?
As you know, anyone with permission to connect and browse the SSAS DB will be able to reverse engineer it using Visual Studio.
No, it is not.
The problem you have is that you think that there is anything hidden there - it is not. This is like asking "can I somehow hide from the driver how the car cockpit looks like".
The information VS uses is the same any client use to efficiently navigate and use the database. WIthout it, you could not do any analysis using... i.e. Excel.
Given that being sliced and diced and analyzed is the PURPOSE for the data, and one needs to know the structure for this.... there is simply no way to hide this knowledge.
If there is anything special you try to achieve - open another question, but given how LITTLE (extremely little) logic a SSAS cube contains... there is IMHO no way to hide it. See, this is like a SQL database - ONLY the tables, no triggers etc. - you could not hide that and expect clients to still provide full experience. They need to know what data is where.
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?
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 in the process of designing a database for the first time outside of the classroom in order to make a future java application work with complete desired functionality. As I am trying to design entity relationship diagrams and tables, I find myself always thinking about my java project that is required later. I am beginning to wonder if this is making me more confused and if I am making this more difficult for myself; I am beginning to get nervous that I might not be skilled enough yet to pull this off.
Should I just focus on producing the most normalized database I can and trust that it will allow for my application to do everything it needs to do?
Or,
Should I definitely be keeping my future application in mind with each step of database development to ensure total functionality?
Edit: I would also appreciate any recommendations on free database design tools.
Databases are notoriously hard to refactor, so if you know about something you haven't gotten to yet but are definitely going to do, you need to consider that in your design. This is espcially true if the future something (For example reporting) is going to need to look at lots of records or is going to need moment in time data as opposed to doing calculations on the fly. This is the difference between storing the cost of an order vice calculating it based on current prices for instance. If you just look at the order process, you may thing it is ok to just calculate the price, but reporting will need to know what the price was at the time the order happened or the financial records will be messed up.
You might read this:
What are the general guidelines and best practices to keep in mind while designing database for an application?
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 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.