I am a beginner but know the basics and am peering into more advanced data mining and stored procedure routines. I have learned small concepts that mimic C# Design Patterns such as looping structures but have not seen much (on the web) about SQL Design Patterns.
I ask because I ran across this book http://www.amazon.com/SQL-Design-Patterns-Programming-Focus/dp/0977671542 but have also always been told that you will find better information on sites like Stack than in a book.
I've been told that for programming professionals Design Patterns are a must. Is this also the case for SQL programmers?
*(Wasn't sure if this belonged on Meta or not. It's not a question about the site but is a general discussion question)
Design patterns for SQL are very useful as well. Is it any good to gather data if you do not store it properly and retrieve it back to make useful decisions?
I have found Joe Celco's books very useful on database design patterns. http://www.amazon.com/Joe-Celko/e/B000ARBFVQ
Of course you should read books. In the first place they tend to be written by people recognized for their expertise (not just anyone who happens to log into the site) so the information is likelier to start out as more accurate. Then they have editors who help make the presentation of the information better. Finally a good book should discuss in more depth than an SO post can do and thus you will get information at a deeper level than just the code to fix your current problem. This means your understanding will grow and you will know why you would do X vice Y and be able to expand that understanding to new problems.
DBAs who don't read books probably don't understand the internals of how the database works very well and are likely to be less effective than those who do read in depth about their profession.
A book I recommend is:
http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=pd_sim_b_1
Also books on performance tuning are critical to read if you want to use good patterns in your SQL. A huge number of performance problems are caused by badly designed SQL. YOu should know what works well and what doesn't. Those tend to be databse backend specific, so look for ones realting to the type of databases you support.
Related
I've been spending a considerable amount of time learning MongoDB as part of the MEAN stack (I'm new to the MEAN stack), and I feel like I'm just barely starting to get the hang of it. Recently, however, my supervisor at work (who's an experienced programmer) suggested I learn relational databases (it could be that it's used by more companies), and I have taken his suggestion to heart since I'm only a junior developer, and would like to move up soon. My personal goal/project is to build a social networking site where one group of users have the ability to search for another group of users (and most likely charge a membership fee). Would the database matter for a project like this? I would love to kill two birds with one stone by learning something (and learning it really well) that could be used in my personal project, and in a professional job.
I'm certainly open to learning more than one language, but I need a starting point, so I need something that will help me accomplish my personal goal. Since I've spent a considerable amount of time with JavaScript (as oppose to, say, Python), having to learn relational databases concerns me. Are there any downsides to just sticking to MongoDB?
Thanks in advance!
The first thing you need is to assess what type of data you are going to deal with (will it be structured, easily represented by tables, or it will be more of the non-structured type).
If structured, RDBMS is the way to go.
Incidentally, as far as I know, the first versions of Facebook were implemented using MySQL (the type of DBMS your boss was referring to).
Farid, as you're a junior programmer, I'd suggest you to learn as much as possible of both approach.
The knowledge acquired on one of them will also help you getting the most from the other (as they both concern data, how to structure it and how to query it).
Also, in the day by day job (unless you specialize only in large sites where scalability is the first concern) you might encounter RDBMS more frequently than NoSQL choices.
Both technologies have pro and cons and, unless you know both sides (at least documenting yourself, if not by direct experience) you might go for one solution when the other could have been preferable.
Well, anyone have concern about learn SQL (and use JOIN), but:
One day, you don't know how, you will use it (or understand it), so perhaps is better take a moment for SQL (it's the most widespread)
MongoDB is good if you development a REST service, but if you want make a social network like project, perhaps is better look at Graph database.
Perhaps that video can help, is an overview of SQL vs NoSQL.
I have been working on SAP technology for the last 2.5 years.
As there were so many technical concepts, I couldn't get a single source where I can learn about everything related to it. I didn't get the confidence of mastering all the technical concepts.
Please help me out if you have faced such an experience and how you overcame it.
Suggest some books or a methodology you followed which may be helpful.
Note: I have already worked in Java/J2EE. I am confident enough in mastering the concepts.
Obviously the (or rather a) correct approach would be one that works for you, the conclusion being that you don't know whether the approach was correct until you've tried it. :-)
Enough philosophy - my suggestions would be:
Learn how to read the SAP Online documentation. That's a bit different from reading other documentation - the SAP docs are littered with information about legacy techniques that you don't really need. Learn to identify and skip these parts - you can always come back later.
Develop a knowledge of the data dictionary. It's really at the heart of all things, and if you can't navigate there and read the structures, you're lost. Start reading the chapter in the online docs at http://help.sap.com/saphelp_webas620/helpdata/en/cf/21ea0b446011d189700000e8322d00/frameset.htm.
Read http://help.sap.com/saphelp_webas620/helpdata/EN/fc/eb3138358411d1829f0000e829fbfe/frameset.htm. I know that's a lot of stuff, but it's available for free, and almost everything is in there. Again, do a "fast indexing run" first to get a feeling of what's inside there, then dig into the basic concepts. ABAP at its lowest level isn't fundamentally different from other imperative / procedural languages.
Follow the example programs (transaction code ABAPDOCU). Learn how to use the debugger (vital!) and understand what's going on in the demo programs.
Once you've got a mental model of the basic language, take a look at ABAP Objects. If you already know Java, there should be no problem with the basic concepts, but there are a few specialties.
Feel free to ask if you run into something you don't understand.
There is no single source of information that will provide you with everything you have to know, especially since some of the knowledge is very specific to the context (FI, MM, IS-H, ...).
Our company, being rather small, doesn't have much in the way of policies and procedures for good development. When I first started, I developed some, but we now need to update these in a more formal manner. Since I don't have much experience in writing policies (I've written plenty of instruction sets, so I'm not as worried about the procedures, though still thoughtful), I want to ask the community for tips and advice on writing good policies and procedures for software development. Thanks.
Some of policies depend of your programming languages, but :
Write naming rules to uniforme the code of your team
Write general coding rules like KISS principle
For customers and bugs management, take a look at ITIL
For delay and tasks management, I recommand Scrum method
Write a chapter about design patterns (design pattern head first)
If you want more formal procedures, have a look at ISO 90003
Some other books can help you like Code complete
My humble opinion... don't overdo it :) A small team needs a shared understanding and vision of how things work. While policies serve communications in large companies, they tend to devolve into power struggles with smaller groups. I found traditions grown out of experience more useful than procedures stated ahead of time.
That said, software dev establishments need some systems for source control, issue tracking, and a place for dropping documentation. Clarity around how decisions are made is immensely useful, as is an understanding of what a project looks like.
Avoid fights on whether there has to be a space character before the semicolon like the plague, and make sure to leave enough room for fun...
I'm a vb.net developer in small IT department and I'm having trouble making the leap to programming exclusively with objects.
I understand the principles of OOP, design patterns, unit testing, etc, but when it comes to developing my applications, either my object design is poor, or I skip building with objects altogether. I know how to create unit tests, but don't have confidence in the ones I create.
I build almost exclusively data-driven data entry/reporting kind of apps. In most cases, much of the business logic is in the database in stored procedures and UDFs. I developer ASP.NET and Winforms applications to internal and external customers.
I've asked about small projects here on the Stack that I can look at to get an idea of good design and testing, but came up mostly short. I've read a bunch of books on design.
What are some good first steps toward breaking away from my old 'VB 6' ways?
Thanks!
A co-worker got me hooked on the book Domain Driven Design by Eric Evans. It really started to get me to move away from data driven development when nessasary.
Also getting involved in a .NET user group in your area will go along way in helping you find people who are more than willing to help you out.
I hear ya, man. I too, live in your world. A world where business people demand reports. Complex reports. Reports which are easily built with complex stored procedures. In this world it is easy to think that the database is king and it drives the application. That line of thought leads to complex database TSQL code, views, functions, and stored procedures.
Certainly if it is truly a report you need then a complex sql statement may be the answer. However, you want to know how to break out of that data-driven world and enter an object oriented world.
I think typical OO design tutorials won't do you justice. Who cares if a dog is a type of an animal and a German Shepherd is a type of dog. That doesn't explain how you do business at your job. Furthermore that is only an example of OO inheritance. Other OO patterns such as composition and dependency injection are much more useful most of the time.
The way I think you should approach your next project or task is to forget about the database temporarily. Pretend that you live in a magical world where getting data from the database doesn't have to happen and writing data back to the database also doesn't have to occur. You live in a world where your objects are always populated with the right data. Model your objects first in that abstract world. After doing so, then (and only then) concern yourself with the messy implementation details of getting and writing to the database. The database is only there to persist your data. Your data is alive because you've already modeled it to fit within the rules of your domain.
Understanding UML will help tremendously for this type of modeling. Use UML designs first to model your domain. Then code to those designs. Then work them to fit within the constrains of your database.
Eric Evans "Domain Driven Design" is a great book which hammers this and many other related points home. He makes the point that domain modeling is THE crucial element to successfully modeling an application. He goes on to point out that object oriented design lends itself better to domain modeling than any other type of programming paradigm.
Good luck. Once you embrace the fully modeled, fully typed world of objects, you'll never want to parse another dataset again.
Try to read code from projects that has been developed under OOP aproach.
Imagine how your code would looks like if you coding as the example that you are reading.
Be tough with your own code, try until you are satisfied and then when you read it after 3 months you'll find many other new things to improve it.
Remember the KISS rule, all the parts will fit as you still coding following the OOP principles.
Be disciplinated. It's easy to succumb to the old way but don't give up.
Remember Dijstra words:
...when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself "Dijkstra would not have liked this", well, that would be enough immortality for me.
He lives inside each of us =). And you have done the most important thing, you really want to learn how. That's the main obstacle with VB6 developers when they change to VB.NET.
In VB6 it easier.
In VB6 always works faster.
It's the same thing...just looks better.
VB6 has a lot more functions.
Looks familiar?
There are two things I'd recommend:
Look into UML class diagrams and play around with the class diagram tool in Visual Studio. The purpose of OOP is to make things more "conceptual" by thinking in terms of objects and, at least for me, class diagrams help to do that.
Read through some good design patterns, like the Decorator or Factory method pattern. Since most design patterns take full use of object-oriented design and also are usually well described, they can really help get the concepts down.
I was in your shoes a few years back. I remember reading an article that estimated you would spend anywhere from 6 months to a year just reading about object-oriented development before you would start to "get it".
I started by just trying to introduce objects in my day-to-day procedural programming. Then I tried getting as much processing out of the UI as I could. Then I tried creating "layers" for my business logic and data access. I understand a lot of your business logic may already be in the database but it wouldn't hurt to have a BL layer in place in case that changed. Right now it can pretty much function as a pass through.
I have Eric Evan's Domain-Driven Design still to read but a couple of books that have helped me are "The Object-Oriented Thought Process" and the one that I'm currently reading, "Microsoft .NET: Architecting Applications for the Enterprise". This book, while maybe more than you really need right now, is the first that has helped me really understand the layers and how to implement them.
Anyway, good luck with your journey. Just remember, it's going to be a process, not a destination!
In addition to the advice given in the other answers, you should ditch the VB.NET and learn C#.
It won't do everything for you, but it will help you get out of your old ways of thinking.
Closed. This question needs to be more focused. It is not currently accepting answers.
Closed 1 year ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I've never had much need for programming with databases. Since their use is so widespread it seems like a good thing for me to learn. SQL seems like the place to start, possibly SQLite and maybe the Python bindings. What would you recommend for someone new to this? Libraries, tools and project ideas are all welcome.
Structure Query Language (SQL) is the language used to talk to database management systems (DBMS). While it's a good thing to learn, it's probably best to do it with a project in mind that you'd like to do. It's funny you say you've never had a need, because I'm the opposite, almost every program I've ever written has used a database of some sort. The vast majority (mostly web-based) revolve around using a database.
Learn about relations and database architecture. This means how to structure your tables, make foreign keys and relations.
For example, you might have a movies database. In it, you store information about the Movies, Studios that released the movies, and the Actors in the movies. Each of these becomes a table. Each Movie is released by one Studio. Since you don't want to store duplicate the studio information (address, etc) in each Movie entry, you store a relation to it, so each Movie item contains a reference to a Studio item. This is called a one-to-many relationship (one studio has many movies). Likewise, you don't want to store Actor information for each Movie. But one Actor can be in many Movies, so this is stored as a many-to-many relationship.
Learn SQL itself. SQLCourse is a good place to get started, but there are many other books and resources. SQL is a standard, but each RDBMS has its own vendor-specific ways of doing certain things and other limitations (for example, some systems don't support sub-queries, there are several different syntaxes for limiting the number of rows returned, etc). It's important to learn the syntax for the one you're using (eg, don't learn Oracle syntax and then try and use it in MySQL) but they are similar enough that the concepts are the same.
Tools depend on the DBMS you use. MySQL is a pretty popular database, lots of tools are available, and lots of books. SQLite and Postgresql are also quite popular, and also free/open-source.
If you can, you really want to find someone who knows how to use it, and pick their brains. That's because there are a lot of important principles (eg 3rd normal form) which will are a lot easier to learn through discussion rather than from books.
If you want to teach yourself, you should learn the syntax for doing basic selects, joins, updates, deletes, and group by queries. You should also learn the "Swiss army knife" of selects, the CASE statement. Too many people don't. Many of the tutorials recommended in this thread will do that. Then you need to try to solve SQL problems. I'm sure that Joe Celko's SQL Puzzles and Answers is a good source of them, though it may be a little advanced.
This will let you actually write SQL. But you still need to learn how to organize a database. Which for most purposes means that you really need to learn what 3rd normal form looks like. You don't have to be able to give a formal definition of it, just recognize it when you see it, and know how to adjust something to be in that format.
Lots of references will explain it, but you won't know if you're reading them correctly. This is where it really, really helps to have access to someone who can look at a table layout and tell you, "That's right" vs "That's wrong, here's what needs to be changed." Failing all else, you could post a question here with a proposed layout. But a back and forth discussion with a live person would still be preferable IMO.
Try Wikipedia, http://www.w3schools.com/sql/default.asp and http://www.sql-tutorial.net/ Also check YouTube for SQL Videos.
You are correct, SQLite is a great place to start because it is free, lightweight, and available on many platforms. This is only a start though. SQLite is very liberal on SQL syntax and lacks an intneral programming language like DBMS systems have. Still, if you want to start and learn with minimal overhead, SQLite is the way to go.
SQLite is nice and they have really nice documentation, however you should be aware that it is not a full featured SQL database like MySQL, Postgres or the commercial variants. SQLite's API relies on callbacks which is a fine model, but not all database APIs work that way. If you are familiar with Perl, then DBI is another nice way to explore SQL.
/Allan
"A Gentle Introduction to SQL" - You can even practice "live queries" right on this tutorial website.
http://sqlzoo.net/
I always recommend The Practical SQL Handbook for a good starting point for beginners - especially those who have seen SQL but never understood how to build up a query them selves or how they work.
All Celko's books are great.
Hernandez's Mere Mortals book is good.
Ken Henderson's books are also excellent.
Reading up a bit on relational algebra is a good way to understand the underlying concepts of relational databases.
Jeo Clecko's SQL for smarties is excellent.
I recommend the exercises at this site: sql-ex.ru
You can even get a certificate if you do the right.
Start with Ideone and try queries on line just with a web browser.
If you program using the .NET framework, then learning LINQ might be a good place to start. The LINQ "engine" will handle the back end communication with the database (or objects, or entities, or XML, etc.) for you. If you want to dig deeper, you can explore the SQL generated by the LINQ that you write.
If you already know a thing or two about web applications, then that would be a good place to start. Nearly every serious webapp uses an SQL database as its backend.
The folks at Head First have come out with a book. Going by how good their other books are, I'd recommend this one. Haven't read it yet though. (LINK)
You may want to consider starting with MySQL as it is widely documented and very easy to get started with. You can download the Community Edition and then add the GUI Tools and you'll both GUI and command line interfaces.
Read a book to start learning about SQL. I read Beginning SQL Queries from Apress not long ago, and found it clear and logically written for a beginner (I reviewed it for a colleague).
I learnt 90% of what I know about SQL from here. In 1997.
I think it still stands up.
Hey although not complete it's great to get hands on with SQLite as mentioned above, Google 'Learn SQL the hard way' and there is an online book which you can work through which uses SQLite.
Google is great for downloading pdf's for free 'Cough Cough' but try http://www.sqlfiddle.com/
It's an online platform which is free! No log in required just go to their page, create your database in whichever language you want (That's the best bit I choose T-SQL as I'm learning that), and then you can query it as much as you like. I'm learning with a pdf file which has opensource SQL files you can download to follow along, and SQLFiddle has been great to learn vendor specific SQL.