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 always thought an SQL compiler would break but apparently nesing can nearly be infinite. Is this code to be trashed immediately or is there some glimmer of hope that something like this can function?
This query doesn't really belong to me so I cannot post it... However let's just pretend it is this one:
[SELECT /*+ NOPARALLEL bypass_recursive_check */
SP_ALIAS_190,
((CASE SP_ALIAS_191
WHEN 1
THEN 'PROVIDER::ALL_PROV::'
WHEN 0]
Clearly, you've never seen the SQL that comes out of the Sharepoint DAL.
If the query is generated by a tool (or by code), then it may be relatively simple to maintain (in the sense that the query generation code may in fact be well written and maintainable)
I ran into a problem similar to this recently and I came to a decision by considering a couple of things:
How long is this going to take to maintain vs. rewrite?
How critical is this? There may be a lot of logic that may be difficult to unravel and the value in the fact that "it works" exceeds the value from an immediate rewrite.
And of course, there was the political decision management had to make concerning risking explaining why something that was recently created would have to be rewritten.
In the end (for me), find + replace was my friend.
Refactor it using the WITH statement.
Add lots and lots and lots of comments.
If you break it into pieces that can be managed, you stand a much better chance.
If it contains allot of nesting I would say no.
Like any code no matter what language, you should only look at re-writting it because you can make it more efficient or easier to understand.
Based on my experiance I have been able to reduce badly written SQL 4 to 5 times its size and many times its performance because the origonal auther really had no idea.
If you think that's bad, you should see Industrial Logic's sample video on code smells: Technical Debt. Definitely not autogenerated.
Is it possible to maintain a 43 page function, say, in C#? The answer is obvious ;). I just cannot imagine this. If I were you I would break it into smaller parts.
Two things:
Will only machines ever need to read this SQL?
Are you stuck with the underlying schema?
If you have a 43 page query and you answered yes to the first two questions, welcome to SharePoint development
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 5 years ago.
Improve this question
I read both the Microsoft Docs and this article. I however can't seem to find where I could only use cursors and not something else so I'd appreciate If someone could give a few examples.
I also came across this answer on stackoverflow and Jeffrey Hantin gave me more doubts.
Imagine a command which must get a literal parameter like BCP.
Try to read 100 XML files living somewhere on your disc and you have their path and filenames in a table.
In this case you will create the statements dynamically and use EXEC to run each separately.
This might be any kind of loop, but a CURSOR seems to be the closest.
The general answer is: Avoid loops, most needs can be solved without using a loop. With SQL one should use set-based approaches over procedural approaches.
I find I only ever use cursors for administration tasks. For example I have a script that runs through my high activity large tables. That rebuilds the indexes overnight that query itself is pretty set based. However I have multiple customer databases on the same box with the same structure. I would wrap the maintenance script in a cursor that pulls out the database names and loops through them.
I find this reduces the amount of work I have to do, as the list of databases to work through is generated by the cursor. If I add customers/ delete customers the maintenance is unaffected. If I run up a new box I can add that as part of the set up process so when I get round to setting up a customer system on the new box it is automatically being maintained.
Here is a sample of somebody using the same concept to backup all of their databases. https://www.mssqltips.com/sqlservertip/1070/simple-script-to-backup-all-sql-server-databases/
Same benefits that I've mentioned in that it is defined once and whether you add remove or move databases they are already automatically in the backup plan
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've just started playing around with Node.js and Socket.io and I'm planning on building a little multi-player game. Probably something simple like each player has a character that they can run around in an arena and try and kill each other.
However I'm unsure how best to store the data. I can imagine there would be some loose relationships between objects such as a character and its weapon but that I would likely load these into the system by id as and when they are required and save them back out when I no longer need them.
In these terms would it be simpler to write 'objects' out to file instead of getting a database involved. Use a NoSql document database or just stick to good old Sql server?
My advice would be to start with NoSQL.
Flatfile is difficult because you'll want to read and write this data very, very often. One file per player is not a terrible place to start - and might be OK for the very first prototype - but you're going to be writing a huge amount. File systems are not good at this. The one benefit at prototype stage is you can debug quick - just cat out the current state of a user. Using a .json file, or similar .yaml format, will start you on your way very rapidly (and you can convert to the NoSQL approach as the prototype starts coming together).
SQL isn't a terrible approach. If you're familiar with this, you'll end up building a real schema, and creating a variety of tables and joining the user data against them quite a bit. This can be a benefit for helping you think through your game, but I think you'll end up spending a lot of time trying to figure out how to normalize your data and writing joins. Since it seems you're unfamiliar with the problem (thus are asking the question), you're likely to do this wrong (and get in the way of gaming awesomeness) and/or just spend too much time at it.
NoSQL - using a document store model - is much like just reading an writing a user object. You'll end up re-writing your user object every time - but this kind of access (key-value, accessed by the user id) is hyper efficient. You'll probably get into a prototype really, really quickly, and to the important aspect of building out your play mechanism. Key-value access is highly scalable in the long run.
If you want to store Player information, use sql. However if you're having a connection based system. As in something where you only need to store information while the player is connected and after the connection is lost you don't need to "save"; then just store it in Memory.
Otherwise, I would say that you should stick with Sql. Databases are optimized, quick, tried, tested and true. You can't go wrong with a Sql database.
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 9 years ago.
Improve this question
How to make a data manipulation language like SQL, and implement the basic functions like
insert, join, natural join
I tried to search online, but I didn't get any proper link, where I can start from. Most of the results go towards making a SQL parser.
So I wanted to ask
What is the basic idea behind making a DML?
How should I be manipulating the data?
Which language or platform should I be using to implement it?
If possible, please post any links of past works in this field.
The search terms you're looking for are relational algebra and relational calculus. I'd rather not go into too much detail, since this usually takes about 6 weeks to cover in a college databases course.
The basic idea is that SQL is a "relational calculus" in that it describes the result you'd like to achieve. It is the job of the DBMS to compile this into a "relational algebra," which describes how to analyze the data.
Ref points 1 and 2 of your question:
I would start off by reading up about some of the theory behind SQL. Chris Date's books (http://en.wikipedia.org/wiki/Christopher_J._Date) are a good place to start.
Point 3.
Presumably you'll have to learn this language. I'd pick something modern with nice high level constructs, and built in String manipulation, Ruby, Python, C# or, Java?
Good luck.
You first need to implement all the functions to do basic operations such as projection, filtering, joining, indexing... Once this functionality is in place, you need to parse SQL, create a queryvexecution plan that will then call your API to get the results. This is of course a very crude description. I would suggest to read open source databases code and documentation such as mysql.
See Studying MySQL, SQLite source code to learn about RDBMS implementation for similar question.
See also
http://en.m.wikibooks.org/wiki/Design_of_Main_Memory_Database_System
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 4 years ago.
Improve this question
As background, I'm one of two developers in my department. I got into computers my freshman year in high school (1986) and have no formal education. I got into MS Access a little bit in 1994 and more seriously beginning in 2003. I'm self-educated, have always tried to learn as much as I can about database design, and while I believe I know a lot I also know I don't know everything.
The other developer in my department, according to his resume, has a degree in computer science and has been doing IT work, including web design and database design, for about 8 years. He was hired into my department last December. I've been very surprised by what I see as a very fundamental lack of knowledge about the basics of database design and SQL and have been trying to figure out if at least part of the problem is I'm expecting too much or maybe don't know as much as I think I do.
Hence my question. Please note we are 100% MS Access, but I believe this question applies to about any SQL database. This developer was tasked to take a spreadsheet and convert it into a database. Part of the spreadsheet involved tracking inventory for batteries. In the spreadsheet, the column titles were Date and Count. But the data in the date column was a mix of dates and batch numbers. So this developer created a table with a numeric field to contain both the batch number and the date and a second boolean field called IsDate to indicate what value was in the field.
I disagree with this approach and would have created two separate fields, a date field for the date and a numeric field for the batch number. When I suggested this approach, he seemed to not only not understand why but also to get a bit angry about having to change his design.
Which approach would you recommend? Also, assuming everyone agrees with my approach - of course you will! ;) - if you had a developer with this supposed level of experience, would you consider him worth keeping and worth investing the time and effort to educate him?
My own rule of thumb here is:
Always keep data in a native datatype.
This helps comparing, sorting, finding and grouping - especially in a database - and makes your storage less prone to query errors. Moreover, you're not required to use another predicate (AND isdate) when accessing the data. Hence, I think your approach is correct.
Your colleague's approach seems not to be a matter of high education, but one of a personal approach. I've seen workers with PhD who could well listen to a well-reasoned argument, and freshmen who made grave mistakes and would not listen to a polite advice.
I'd most definitely store the date and the batch number in different fields of the appropriate type - setting each with the relevant content or as NULL if no value was available. By doing this you'd be able to see what data you actually have available and perform meaningful operations on that data.
In terms of you second question, I guess it would really depend on what the developer in question said when you asked them why they'd chosen the approach they did.
You are right.
Only under severe memory restrictions might (note might) this kind of architecture be acceptable.
As to dealing with him, I would first talk to him and fiugre out why he chose the given approach, this is something that might have been common in Access Databases 10 years ago (but even then there was enough disk and memory space to not have to do these kind of tricks).
His reluctance to talk about his design is a worse indicator of his abilities than the design itself. Even the most misguided design should have been based on a structured approach or idea. In my mind it is not a bad thing to be wrong, it is a bad thing to create random structures. But not knowing your requirements it is hard to suggest whether it is worth keeping him or not.
Is one of you the 'senior' hierarchy wise or are you sharing responsibilities ?
Point out that he is breaking first normal form by doing so. Be able to describe 1NF 2NF and 3NF before trying to impress him with you fancy pants knowledge.
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 6 years ago.
Improve this question
I am currently doing some kind of reporting system.the figures, tables, graphs are all based on the result of queries. somehow i find that complex queries are not easy to maintain, especially when there are a lot of filtering. this makes the query very long and not easy to understand. And also, sometimes, queries with similar filters are executed, making a lot of redundant code, e.g. when i am going to select something between '2010-03-10' and '2010-03-15' and the location is 'US', customer group is "ZZ", i need to rewrite these conditions each time i make a query in this scope. does the dbms (in my case, mysql) support any "scope/context" to make the coding more maintainable as well as the speed faster?
also, is there a industrial standard or best practice for designing such applications?
i guess what I am doing is called data mining, right?
Learn how to create views to eliminate redundant code from queries. http://dev.mysql.com/doc/refman/5.0/en/create-view.html
No, this isn't data mining, it's plain old reporting. Sometimes called "decision support". The bread and butter of information technology. Ultimately, play old reporting is the reason we write software. Someone needs information to make a decision and take action.
Data mining is a little more specialized in that the relationships aren't easily defined yet. Someone is trying to discover the relationships so they can then write a proper query to make use of the relationship they found.
You won't make a very flexible reporting tool if you are hand coding the queries. Every time a requirement changes you are up to your neck in fiddly code trying to satisfy it - that way lies madness.
Instead you should start thinking about a meta-layer above your query infrastructure and generating the sql in response to criteria expressed by the user. You could present them with a set of choices from which you could generate your queries. If you give a bit of thought to making those choices extensible you'll be well on your way down the path of the many, many BI and reporting products that already exist.
You might also want to start looking for infrastructure that does this already, such as Crystal Reports (swallowed by Business Objects, swallowed by SAP) or Eclipse's BIRT. Depending on whether you are after a programming exercise or a solution to your users' reporting problems you might just want to grab an off the shelf product which has already had tens of thousands of man years of development, such as one of those above or even Cognos (swallowed by IBM) or Hyperion (swallowed by Oracle).
Best of luck.