Sabtu, 26 September 2015

SQL vs NoSQL: How to Choose


SQL databases:
    • store related data in tables
    • require a schema which defines tables prior to use
    • encourage normalization to reduce data redundancy
    • support table JOINs to retrieve related data from multiple tables in a single command
    • implement data integrity rules
    • provide transactions to guarantee two or more updates succeed or fail as an atomic unit
    • can be scaled (with some effort)
    • use a powerful declarative language for querying
    • offer plenty of support, expertise and tools.

NoSQL databases:
    • store related data in JSON-like, name-value documents
    • can store data without specifying a schema
    • must usually be denormalized so information about an item is contained in a single document
    • should not require JOINs (presuming denormalized documents are used)
    • permit any data to be saved anywhere at anytime without verification
    • guarantee updates to a single document — but not multiple documents
    • provide excellent performance and scalability
    • use JSON data objects for querying
    • are a newer, exciting technology.
SQL databases are ideal for projects where requirements can be determined and robust data integrity is essential. NoSQL databases are ideal for unrelated, indeterminate or evolving data requirements where speed and scalability are more important. In simpler terms:
    • SQL is digital. It works best for clearly defined, discrete items with exact specifications. Typical use cases are online stores and banking systems.
    • NoSQL is analog. It works best for organic data with fluid requirements. Typical use cases are social networks, customer management and web analytics systems.
Few projects will be an exact fit. Either option could be viable if you have shallower or naturally denormalized data. But please be aware these simplified example scenarios with sweeping generalizations! You know more about your project than I do, and I wouldn’t recommend switching from SQL to NoSQL or vice versa unless it offers considerable benefits. It’s your choice. Consider the pros and cons at the start of your project and you can’t go wrong.

Scenario One: a Contact List

Let’s re-invent the wheel and implement an SQL-based address book system. Our initial naive contact table is defined with the following fields:
    • id
    • title
    • firstname
    • lastname
    • gender
    • telephone
    • email
    • address1
    • address2
    • address3
    • city
    • region
    • zipcode
    • country
Problem one: few people have a single telephone number. We probably need at least three for land-line, mobile and workplace, but it doesn’t matter how many we allocate — someone, somewhere will want more. Let’s create a separate telephone table so contacts can have as many as they like. This also normalizes our data — we don’t need a NULL for contacts without a number:
  • contact_id
  • name (text such as land-line, work mobile, etc.)
  • number
Problem two: we have the same issue with email addresses, so let’s create a similar email table:
  • contact_id
  • name (text such as home email, work email, etc.)
  • address
Problem three: we may not wish to enter a (geographic) address, or we may want to enter multiple addresses for work, home, holiday homes, etc. We therefore need a new address table:
    • contact_id
    • name (text such as home, office, etc.)
    • address1
    • address2
    • address3
    • city
    • region
    • zipcode
    • country
Our original contact table has been reduced to:
    • id
    • title
    • firstname
    • lastname
    • gender

Great — we have a normalized database which can store any number of telephone numbers, email addresses and addresses for any contact. Unfortunately …

The schema is rigid
We’ve not considered the contact’s middle name(s), date of birth, company or job role. It doesn’t matter how many fields we add, we’ll soon receive update requests for notes, anniversaries, relationship statuses, social media accounts, inside leg measurements, favorite type of cheese etc. It’s impossible to foresee every option, so we’d possibly create an otherdata table with name-value pairs to cope.

The data is fragmented
It’s not easy to for developers or system administrators to examine the database. The program logic will also become slower and more complex, because it’s not practical to retrieve a contact’s data in a single SELECT statement with multiple JOIN clauses. (You could, but the result would contain every combination of telephone, email and address: if someone had three telephone numbers, five emails and two addresses, the SQL query would generate thirty results.)

Finally, full-text search is difficult. If someone enters the string “SitePoint”, we must check all four tables to see if it’s part of a contact name, telephone, email or address and rank the result accordingly. If you’ve ever used WordPress’s search, you’ll understand how frustrating that can be.

The NoSQL Alternative
Our contact data concerns people. They are unpredictable and have differing requirements at different times. The contact list would benefit from using a NoSQL database, which stores all data about an individual in a single document in the contacts collection:

{
  name: [
    "Billy", "Bob", "Jones"
  ],
  company: "Fake Goods Corp",
  jobtitle: "Vice President of Data Management",
  telephone: {
    home: "0123456789",
    mobile: "9876543210",
    work: "2244668800"
  },
  email: {
    personal: "bob@myhomeemail.net",
    work: "bob@myworkemail.com"
  },
  address: {
    home: {
      line1: "10 Non-Existent Street",
      city: "Nowhere",
      country: "Australia"
    }
  },
  birthdate: ISODate("1980-01-01T00:00:00.000Z"),
  twitter: '@bobsfakeaccount',
  note: "Don't trust this guy",
  weight: "200lb",
  photo: "52e86ad749e0b817d25c8892.jpg"
}

In this example, we haven’t stored the contact’s title or gender, and we’ve added data which need not apply to anyone else. It doesn’t matter — our NoSQL database won’t mind, and we can add or remove fields at will.

Because the contact’s data is contained in a single document, we can retrieve some or all information using a single query. A full-text search is also simpler; in MongoDB we can define an index on all contact text fields using:

db.contact.createIndex({ "$**": "text" });
then perform a full-text search using:
db.contact.find({
  $text: { $search: "something" }
});

Scenario Two: a Social Network

A social network may use similar contact data stores, but it expands on the feature set with options such as relationship links, status updates, messaging and “likes”. These facilities may be implemented and be dropped in response to user demand — it’s impossible to predict how they will evolve.

In addition:

Most data updates have a single point of origin: the user. It’s unlikely we’ll need to update two or more records at any one time, so transaction-like functionality is not required.
Despite what some users may think, a failed status update is unlikely to cause a global meltdown or financial loss. The application’s interface and performance take a higher priority than robust data integrity.

NoSQL appears to be a good fit. The database allows us to quickly implement features storing different types of data. For example, all the user’s dated status updates could be placed in a single document in the status collection:

{
  user_id: ObjectID("65f82bda42e7b8c76f5c1969"),
  update: [
    {
      date: ISODate("2015-09-18T10:02:47.620Z"),
      text: "feeling more positive today"
    },
    {
      date: ISODate("2015-09-17T13:14:20.789Z"),
      text: "spending far too much time here"
    }
    {
      date: ISODate("2015-09-17T12:33:02.132Z"),
      text: "considering my life choices"
    }
  ]
}

While this document could become long, we can fetch a subset of the array, such as the most recent update. The whole status history for every user can also be searched quickly.


Now presume we wanted to introduce an emoticon choice when posting an update. This would be a matter of adding a graphic reference to new entries in the update array. Unlike an SQL store, there’s no need to set previous message emoticons to NULL — our program logic can show a default or no image if an emoticon isn’t set.

Scenario Three: a Warehouse Management System

Consider a system which monitors warehoused goods. We need to record:

    • products arriving at the warehouse and being allocated to a specific location/bay
    • movements of goods within the warehouse, e.g. rearranging stock so the same products are in adjacent locations
    • orders and the subsequent removal of products from the warehouse for delivery.

Generic product information such as box quantities, dimensions and color can be stored, but it’s discrete data we can identify and apply to anything. We’re unlikely to be concerned with specifics, such as laptop processor speed or estimated smartphone battery life.

Our data requirements:

  1. It’s imperative to minimize mistakes. We can’t have products disappearing or being moved to a location where different products are already being stored.
  2. I hope these scenarios help, but every project is different and, ultimately, you need to make your own decision. (Although, we developers are adept at justifying our technological choices, regardless of how good they are!)
  3. In its simplest form, we’re recording the transfer of items from one physical area to another — or removing from location A and placing in location B. That’s two updates for the same action.
We need a robust store with enforced data integrity and transaction support. Only an SQL database will (currently) satisfy those requirements.


Source : http://www.sitepoint.com/sql-vs-nosql-choose/

Sabtu, 18 April 2015

Love Story of Someone

Halo para blogger sejati, udah lama gak posting di blog…heheheh… Kali ini gw bakal ceritain masalah cinta gw di masa kuliah untuk para blogger sekalian. Pada 31 Agustus 2010 gw berkenalan tidak langsung sama cewek yang gw suka yang bakal gw ceritain ini nih, di antara semua cewek di kelas gw, dia orang yang menurut gw agak lumayanlah..hehehe. Kalau dibilang cakep sihhh….hemmm…gk juga…trus apa yang buat gw bilang klo dia itu lumayan? Dia itu hemm..gw akuin dia itu manis dengan rupanya dan tingkahnya walaupun keliatan bawel setengah mampus…hahahaha…but so far I like it..hehehe…Awal gw kenal sama dia menurut gw dia cewek manja yang gak bisa ngapa”in but I’m wrong, dia jauh dari itu ternyata. Tapi di tahun pertama kuliah gw gak punya perasaan yang lebih dari teman sama dia. Trus gmana caranya gw bisa akhirnya bisa jadia sama dia ya? Begini nih ceritanya..hehehe. Semester 6 di kampus gw itu ada tugas yang namanya Penulisan Ilmia yang tingkat kesulitannya setara kayak pembuatan skripsilah…hehehe. Di awal semester 6 gw biasa aja sama dia dan bahkan gw sama dia Cuma tegur sapa aja..hehehe. Tapi di beberapa bulan kemudian dia ngalamin sedikit kesulitan dalam pengerjaan program. Dan akhirnya dia mintol(minta tolong) sama gw dan gw bantuin dia dengan syarat bawa snack cemila saat gw bantuin dia ngerjain itu program..hehhe..gw bercanda sebenenarnya nyuruh dia bawa cemilan..ehhh..dibawain..mungkin krna dia gw bantuin kali yaa…hehehe…Di hari pertama gw ngajarin dia masih abu-abu mau bikinnya kayak gimana, dan gw suruh dia matengin di konsep dia dulu, setelah itu gw suruh dia bikinin kodingan atas tuntunan gw, ya dikerjain sih pastinya…tapi di saat dia ngerjain gw diam aja dan dia buka obrolan dengan curhatan masalah dia sama cowoknya dia, dan gw gak tau saat itu klo dia punya cowok dan siapa cowok yang dia maksud, gw iya..iyain aja selama dia curhat..hahaha…bodo amat..misi gw kan mau ngajarin dia doang bukan jadi pangern cinta yang kasih solusi masalah percintaan..hahaha. Tapi gw gak sekejam itu kok klo cewek curhat, sedikit-sdikit gw masih bener-bener dengarin dia kok. Yang pasti inti dari curhatan dia itu klo dia sama cowoknya lagi gak baik. Makin lama gw ngajarin dia gw ngerasa kalau dia itu makin sering curhat sama gw dan yang awalnya jarang chatting malah suka chat gw dan makin care tapi masih tetap dibarengin curhatan masalah dia sama cwok dia. Menurut gw dia orangnya baik dan dia mau nemanin gw makan klo gw mau makan dulu sebelum mau ngajarin dia. Makin lama kita makin dekat dan gw berubah 99 derajat jadi lebih sering bareng sama dia dan bbrapa sahabat dia ketimbang sama teman gw yang cowok. Gw makin lama bareng sama dia, gw ngerasa nyaman dan seneng bisa bareng dia mulu. Dan selama semeter 6 kita cuma sebatas sahabatan aja, tapi selama sahabatan aja sama dia gw ngerasa dia nyaman dan yang gw liat kalau dia suka sama gw..hahaha….gw bilang gitu krna dia suka megang tangan gw, dan dia sadar. Tapi suatu ketika gw ngeliat dia megang tangan gw trus dilepas sama dia…mungkin dia malu kali yaa…hahhaa..atau grogi..hahha.Selama itu gw sama dia makin lama makin nyaman dan kompak dan gw ngerasa klo gw suka sama dia, suka bukan sebagai sahabat tapi gw pengen milikin dia sebagai cewek gw tapi sayangnya dia udah punya cwok. Tapi yang aneh gw liat dia punya cowok tapi justru jarang jalan sama cwoknya malah seringan jalan sama gw. Disini gw gak pengen rebut dia dari cowk dia kok saat itu, gw murni suka dan boleh dibilang sayang tapi gw gak punya niat buat ngasih tau perasaan gw ke dia yang bisa aja buat hubungan mereka makin hancur. Setiap malam pulang kampus dia suka curhat sama gw dan minta saran dari gw atas hubungan dia sama cowok dia yang makin hari makin gak baik. Dan gw saranin ke dia klo mereka udah sering berantem dan gak ngerasa cocok yaudah mereka putus aja.. gw bilang gitu bukan niat biar gw bisa pacaran sama dia kok..hehehe…tapi gw lama-lama males ddengarin curhatan dia masalah cowk dia yang masalahnya gak jelas bangat dan gak kelar-kelar masalahnya ditambah gw kan suka sama dia..perasaan gw hemmm…blogger pasti taulah..hehehe.Tapi setelah sekian lama gw gak tahan buat nyimpan perasaan gw, di saat hubungan dia blom putus tapi udah di ujung tanduk gw ngomong perasaan gw ke dia dan gw dia ternyata punya rasa yang sama juga sama gw dan dia ngerasa lebih nyaman sama gw ketimbang cowok dia. Dan setelah itu kita belum jadian krna dia masih punya cowok. Makin hari gw sama dia kayak backstreet dari anak-anak kelasan dan gw rasa pasti anak-anak tau klo gw punya hubungan sama dia..hehehe. Makin lama gw chatting sama dia ada satu pertanyaan yang buat gw kaget, dia nanya “mungkin gak ya kita jadian di tanggal 14 feb nanti?” dan gw rasa itu pertanyaan terlalu cepet secara dia masih pacaran walaupun hubungan dia sama cowok dia udah di ujung tanduk.  Sebagai cowok yang baikkk…hehehe..gw bilang gak mungkin krna gak secepat itu juga kalaupun kita saling suka. Dan malam-malam selanjutnya dia chat dan kasih tau ke gw klo dia udah putus sama cowoknya, tapi gw ngerasa bersalah apa krana gw bilang persaaan gw ke dia, makanya dia putus sama cowok dia?, sayangnya dia bilang gak, itu murni keputusan dia. Gw ngerasa senang pastinya..hehehe.
Di saat itu pembuatan aplikasi untuk penulisan ilmiah makin hari mendekati deadline dan dia butuh gw, dan gw selalu ada dari pembuatan aplikasi gw bimbing dia hingga penulisan dia. Dan gw lakuin itu semua dengan senang hati krna bisa bareng sama dia..hehehe. Selama gw bantuin dia bikinin aplikasi-nya, dia juga nemanin gw kalau gw mau makan di kampus di sela-sela istrahat jam kuliah..Walaupun gw sibuk bantuin dia bukan berarti gw gak ngerjain aplikasi gw…tapi gw udah kelar semuanya sebelumnya krna gw kerjnya cepet..hehehe..maklum orang rajin..hehhee. 
Di semester 7 akhir tepatnya di 1 Maret 2014 gw akhirnya jadian sama dia..hehehe…senang bangat rasanya tapi kita masih backstreest dan anak-anak kelasan gak ada yang tau. Tapi sepandai-pandainya tupai melompat akhirnya jatuh juga dan gw ngalamin semakin kita sembunyiin hubungan kita dari anak-anak kelasan akhirnya ketahuan juga..hahahha. Selama pacaran sama dia, hubungan kita dan hari-hari kita makin menyenangkan…hehehe. Dan gw selalu terkesan sama dia yang perhatian bangat sama gw dan gak mau jauh dari gw..hehehe…dan gw juga bingung kenapa mantan dia bisa bosen sama cewek semanis dan selucu ini yaaa..hahaha.
Selama pacaran sama dia bukan berarti gw sama dia gak punya masalah. Kita punya masala dari luar hubungan kita yaitu salah satu keluarga gak menyetujui kita pacaran dengan alasan gw berasal dari suka bata sedangkan dia dari suku maya..hahaha. Selain itu juga kita beda agama, dia katolik dan gw protestan. Buat atasin pacaran gak disetujuin kita gak putus begitu saja tapi kita backstret dari keluarga dan sampai gw nulis cerita ini hubungan gw sama dia masih bisa bertahan.
Sejujurnya gw bener-bener sayang sama dia dan gak mau kehilangan dia, walaupun gw suka bikin masalah yang gak jelas atau dia bikin gw kesel gw langsung bilang putus, tapi itu gak lama putusnya..sekitar beberapa hari aja dan kadang Cuma putus sehari aja..hahaha..itulah saking kita saling sayang. Di pikiran gw smpai saat ini gk akan sia-siain hubungan ini dan gw bakal jaga hubungan ini supaya lebih baik..hehehe.
Beberapa bulan setelah saya menulis cerita ini akhirnya keluarga dia gak terlalu masalahin kita pacaran dan gw luar biasa senangnya, setidaknya perjuangan buat pertahanin hubungan selama ini ada hasilnya…hehehe. 
Hari-hariku tanpa bertemu atau gak ada kabar dari dia gw ngerasa ada yang kurang dan gak bisa fokus bekerja. Semoga dia orang yang selalu ada buat gw untuk hari ini, esok dan selamanya..hehehe.


Sabtu, 16 Agustus 2014

MEMBUAT WEB DENGAN MENGGUNAKAN BOOTSTRAP V.3

Sobat sekalian mungkin untuk orang yang sudah pernah membuat website sudah tidak asing lagi dengan Framework Bootstrap. Boostrap merupakan style web yang tinggal pake saja, jadi untuk memuat web yang responsive sekalipun gak usah pusing script css-nya gimana....hehehe.
Oh ya gw jelasin dulu apa itu yang namanya web responsive, web responsive merupakan web yang memiliki variasi tampilan untuk berbagai layar. Misalnya kita mau browsing di Desktop, Tablet, dan juga Mobile akan memiliki tampilan yang berbeda-beda. Mungkin orang yang masih awam akan bertanya kenapa kok bisa beda? Bukankah klo beda tampilan informasi jadi acak-acakan nanti? Jawabannya adalah perbedaan yang dimaksud disini adalah dari segi struktur tampilan informasi tetapi untuk informasi yang disampaikan tidak berkurang alias gunanya responsive adalah membuat tampilan di berbagai devisce lebih menarik.
Konsepnya seperti ini, kita punya berbagai device.
Layar Device

Untuk membuat tampilan web di berbagai device ini kita tidak perlu koding untuk masing-masing device jika kita sudah bisa menggunakan yang namanya bootstrap yang saya maksud. Karena walaupun ukuran layar berbeda-beda bootstrap bisa handle semuanya tanpa mengurangi informasi. Dan pastinya yang gak jago CSS gw saranin pake yang satu ini nih....hehhee.
  1. Oke langkah pertama kalian download dulu bootstrapnya disini.
  2. Kemudian Download Jquery Download the compressed, production jQuery 1.11.1
  3. Setelah itu ekstrak boostrap yang sudah kalian download sehingga bentuknya seperti ini.
  4. Hasil Ekstraksi Bootstrap
  5. Setelah itu masukkan JQuery yang telah di download tadi ke folder js diatas, sehingga isinya seperti ini.
  6. Memasukkan file Jquery
  7. Kemudian kita coba membuat halaman simple dengan codingan seperti di bawah ini.
  8. Tuliskan script di bawah ini pada notepad/notepad++ dan simpan dengan nama index.html
  9. 1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    <html>
    <head>
    <title>Tutorial Pertama</title>
    <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link href="css/bootstrap.min.css" rel="stylesheet" media="screen">
    </head>
    <body>
    <div class="container">
    <nav class="navbar navbar-default" role="navigation">
      <!-- Brand and toggle get grouped for better mobile display -->
      <div class="navbar-header">
        <button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#bs-example-navbar-collapse-1">
          <span class="sr-only">Toggle navigation</span>
          <span class="icon-bar"></span>
          <span class="icon-bar"></span>
          <span class="icon-bar"></span>
        </button>
        <a class="navbar-brand" href="#">Brand</a>
      </div>
    
      <!-- Collect the nav links, forms, and other content for toggling -->
      <div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1">
        <ul class="nav navbar-nav">
          <li class="active"><a href="#">Link</a></li>
          <li><a href="#">Link</a></li>
          <li class="dropdown">
            <a href="#" class="dropdown-toggle" data-toggle="dropdown">Dropdown <b class="caret"></b></a>
            <ul class="dropdown-menu">
              <li><a href="#">Action</a></li>
              <li><a href="#">Another action</a></li>
              <li><a href="#">Something else here</a></li>
              <li class="divider"></li>
              <li><a href="#">Separated link</a></li>
              <li class="divider"></li>
              <li><a href="#">One more separated link</a></li>
            </ul>
          </li>
        </ul>
        <form class="navbar-form navbar-left" role="search">
          <div class="form-group">
            <input type="text" class="form-control" placeholder="Search">
          </div>
          <button type="submit" class="btn btn-default">Submit</button>
        </form>
        <ul class="nav navbar-nav navbar-right">
          <li><a href="#">Link</a></li>
          <li class="dropdown">
            <a href="#" class="dropdown-toggle" data-toggle="dropdown">Dropdown <b class="caret"></b></a>
            <ul class="dropdown-menu">
              <li><a href="#">Action</a></li>
              <li><a href="#">Another action</a></li>
              <li><a href="#">Something else here</a></li>
              <li class="divider"></li>
              <li><a href="#">Separated link</a></li>
            </ul>
          </li>
        </ul>
      </div><!-- /.navbar-collapse -->
    </nav>
    <div class="row">
    <div class="col-md-8 col-xs-8 col-sm-6">
    <h3>Bagian Content</h3>
    <br/>
    <br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>
    </div>
    <div class="col-md-4 col-xs-4">
    <h4>Bagian Widget</h4>
    </div>
    
    
    </div>
    
    
    <div class="well well-sm text-center">Copyright &copy by Indra Tobing</div>
    </div>
    <script src="js/jquery-1.11.1.min.js" ></script>
    <script src="js/bootstrap.min.js" ></script>
    
    </body>
    
    </html>
    
  10. Jika kalian jalankan di web browser dengan cara double click pada index.html yang disimpan tadi.
  11. Hasilnya adalah seperti pada gambar  bawah ini.
Output
Untuk download source code bisa disini.
Untuk memudahkan kalian mempelajari bootstrap memasang Bootstrap Twitter Offline Docs pada Google Chrome  kalian yaitu di webstore