As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
In most projects, reporting tools such as crystal reports are choosed to display data. There are many reporting tools we can choose. Perhaps some of them is easy to use, but most of them are a little complex.
Developers have to spend some time to learn how to use it, how to make it looks good. Sometimes, it makes develpoer fatigued to trim the table cell or make the cells orderliness. In some complicated situation, we need some style that the reporting tools don't afford. Using the reporting tools means lower the efficiency of development, developers have to build a lot of data schemas to adapt to the data source of reporting tools.
And the performance is also the short of reporting tools. Usually we need install some component to support the reporting. And if we need get some data from multiple joined tables, the performance loss is obvious.
So in my opinion, we can use the html table instead of the reporting tools.
some reasons:
HTML table is easy to be generated.
We can control the style of the table with the css easily.
HTML table is flexiable to embed jquery plug and flash object.
HTML doesn't need the component.
and so on.
As my experience, to finish a report, it takes me less time with HTML.
So why most projects still choose reporting tools?
Because reporting tools have more features than HTML tables
agreed, in C# i use datagrid insted of making a report, but report is easier when it come to print-pages and bills, but its not esy to remember how to do things like functions its a headach
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a strange feeling when it comes about code first migration technology. First of all this is a concept which got its origins in technologies as Ruby on Rails. Not that I do have something against it, please do not get me wrong. What I am not sure about is that if the usage of Code First Migration is a good approach when it comes to high scalable enterprise applications which can include reporting, etc. Basically I am referring at situations where the database design, optimization plays a critical part in the general performance (denormalization, indexing, sharding, etc). My feeling is that Code First Migration brings a major overhead. Am I right, am I wrong? I would really like to hear your opinions.
You're wrong.
EF Migrations has nothing to do with the way your database is designed. It is only a one-time process that merely generates scripts against two versions of the database schema and figures out how to migrate from one to other automatically.
Migrations does not run when the app runs, it doesn't have any overhead or affect performance of the app. It only works with the existing schemas as EF itself generates them. In fact, this process is so generic, it isn't even specific to EF, Migrations can be used to migrate between any two schemas, whether they use EF or not.
As such, it has nothing to do with how the database performs.
The schema is controlled by EF itself, and is dependent upon how you map the database. Yes, it's true that if you just let EF do all the work you might end up with a less than optimal schema, but you can fully control how it generates this by using Fluent Mappings.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We are looking for a reporting suite that will allow us to analyse our data. I'm not sure of the exact terminology for such suites but they are often known as 'Dashboard Software' or 'Database Reporting'
An example is: Wonder Graphs
We are looking for a suite that will integrate with our MySQL database and provide us with:
'Live' graphical Interfaces (Graphs, Charts) for viewing our data which are automatically updated
The ability to 'Drill Down' using these charts to see more specific information.
For example if a chart shows total sales, we want to be able to click on that graph and be shown information on type of sales.
The ability to export to excel
An easy-to-use user interface that allows non-technical users to create and customise their own views or dashboards.
If anyone can list software they use, have used, or know to be good that would be a great help.
If there is an open-source example available that is great however we are expecting to pay for such software.
Let me know if I have been to vague on details.
Thanks in advance,
James
There are a few things to consider. Firstly, how much data do you have? MySQL isn't designed to be an analytics database. If you have a "small amount" of data, then it doesn't matter. However, if you grow or plan to grow, you may want to copy the data over to an analytic database such as Infobright. Infobright does have an open-source option.
On top of the database, you have a few open-source BI solutions that will work very well. Take a look at Pentaho, Jaspersoft, and Actuate/BIRT. Actuate has some great drill down options, and they also have a way to easily get this data to a mobile device.
Full disclosure: I am the open-source guy for Infobright.
In my research I discovered the following site which seems to be a good place to start for anyone looking at this topic:
Dashboard Insight
This site includes a long list of available suites and tools.
We're currently using Dundas Dashboard and have had a lot of success with it. I am pretty sure it has a data source connector for mySQL, you just have to install a driver that they have available on their site.
All in all, great product, a little bit of a learning curve, but we've had a lot of success with it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In 5 days I'm going to ETL interview. It's my first interview on this subject. What question would I be asked? Most likely they will be about MS SQL Server Integration Service.
If possible, provide the answers. =)
If possible, provide the answers. =)
Keep it high-level if you have to, but don't ask a question that couldn't answer yourself.
I agree with Brad that syntax is not important, it's the thought process.
Another idea is to ask them about how they would pack up and move an office. It gives you insight into the same kinds of decisions needed in ETL (prep, actual moving of stuff, and validation), and you might be more comfortable talking about that than the details of SSIS
Think practically. Hand them a printout of a sample file that might need to be imported (possibly simplified to save time). Have them talk about database design, considerations, concerns, possible ways to improve the data. Then bring out a second printout of somehow related and see if they can figure how to validate the one from the other.
Make sure you talk about how much time is available to perform the ETL processes based on business rules and environment.
Require as much pseudo-code as you like, but I personally subscribe to the idea that syntax can be taught cheaply, but learning how to think is a very expensive thing to teach someone; and sometimes it's not even successful.
Also, ask them what standards they would implement if they were to design the optimum layout of the source data. Make sure you consider data distribution beyond your company (if applicable).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Which book is best to learn SSIS. Actually in my project we need to take onput from CVS file and after processing the data in SQL server 2008 we have export it back to excel file. ASP.NET is used as UI for this.
Thanks,
Nabin
I completely agree with Cade in terms of simply working with it. I found that trying to follow specific "tutorials" to try and learn the package didn't really help but having a number of useful resources definitely came in handy.
At work, we had this book kicking around but really it just went over the flow objects available without going into any real-world examples. Jamie Thomson's blogs (here and here) are both excellent online resources though and have been really helpful for me personally.
Try this book:
http://www.amazon.com/Professional-Microsoft-Integration-Services-Programmer/dp/0470247959
The best way to learn SSIS is just to do it. Probably best to start and then refer to the book. Because the tool is so GUI intensive, I tended to get more after reading the book later once I was already familiar with the environment somewhat.
Reading the material some times couldn't solve your real time migration by missing some perticular functionality related to your project. I worked on your scenario case of migrating database to SQL using intermediate CSV or text files.
http://msdn.microsoft.com/en-us/library/dd537533(SQL.100).aspx
we migrated nearly 1TB in 30 min using SSIS 2008.
this could help to get the information on specific properties of souce file according to our requirements.
thanks
prav
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When do you feel that it's appropriate/necessary to take deeper dives into the source code of open source tools to gain an understanding of the toolsets that you use? (nHibernate, StructureMap, Rhino Mocks, etc.)
When it doesn't work the way I expect or I need to implement something that isn't described very well in the documentation or with examples. Usually, it's a response to doing something that I think should work, but not understanding why it doesn't. FWIW, this also applies whenever I can access the source code, regardless of how "open" it is.
I would say there are two scenarios for that:
When the OpenSource product is part of your core business (your company depends on it).
When you want to start contributing to it.
I start diving into the source code anytime I need to know: what does this do? Or why does this not work how I think it should. This comes usually after reading documentation, googling, etc.
Also if it's a framework I've used for a while - it's in my best interest to know the source code a little bit as a reference point to know how it works.
If you want to know how any framework works, you always have to start with: "What would this IoC/ORM framework have to do in order to perform this function." I find thinking from the inside out helps sometimes with frameworks.
You may need to do this if the toolset you are using does not provide functionality that you need, or if there are bugs in your tools.
For example, recently I was using a JavaScript grid library that did not support sorting a column by certain date/time formats - so I had to go into their code and understand how it works so I could come up with a workaround. In the end I had to implement this myself, and contributed the code back to their project.
I think in general, if you are doing something that requires deep diving, then you are probably doing something you shouldn't be doing. When you need to know things at a level where you aren't doing standard things, you need to think really carefully about whether you are doing the right thing or not.
The exception to this is when you are building something where the library is in the realm of your company's core competency. If you are building an online build system, you probably want to know way too much about the underlying build systems (Maven or whatever), and you should probably deep dive on those until you know them well.