Нет будущее за тем, чтобы каждый уважающий себя человек грамотно пользовался плодом трудов других людей, а не изобретал колесо. Постгре разрабатывается огромным числом людей с 1986 года. Я не понимаю зачем делать это еще раз.
Что вы хотите я не понимаю. "и загнался тем что если взять вместе в целом на один сервер со всех сайтов поток пользователей то я могу остаться в яме". Если вас интересует как сделать высоконагруженную систему, которая сможет обсулуживать сотни тысяч пользователей, то во первых эти решения в рамках существующих БД (см репликацию) и во вторых лучше бы решили вопрос как вам получить хотя бы первую тысячу в неделю.
SQL не может ни за что отвечать, это язык, но я кажется понимаю о чем вы. Если вы думаете, что внутри всех СУБД лежит один и тот же "движок" как в php, то это не так.
Каждая СУБД уникальная и состоит из нескольких частей. Я честно говоря уже давно в это не углублялся, и расскажу по памяти, так что за уточнениями в гугл.
Сначала запрос попадает в парсер, где он разбирается синтаксическим анализатором в дерево лексем.
Затем он преобразуется в набор операций реляционной алгебры и попадает в оптимизатор. Оптимизатор штука очень сложная. Основываясь на известных параметрах базы (наличии индексов, примерном количестве строк в таблицах (точное оптимизатор посчитать не успеет и пользуется обычно примерным количеством которое иногда обновляется), информации о разбиении по дерева индекса, другим параметрам (за подробностями в гугл) оптимизатор составляет план выполнения запроса. План запроса в MySQL вы можете посмотреть написав EXPLAIN перед SELECT.
Затем в соответствии с планом выполнения бэкэнд делает запросы в сторадж (подсистему хранения) и достает оттуда необходимые данные. Например строки по индексу или фулл скан или что-то еще. Сторадж соответственно эти запросы обрабатывает, извлекая данные из своих хранилищ. MySQL поддерживает, например, несколько стораджей myisam и innodb. Затем доставая эти данные бэкэнд формирует необходимую выборку, с помощью различных операций над множествами данных. Hash Join, Nested Loops, Merge Join, Sort, etc (подробности в гугл).
Затем выборка передается клиенту.
Это что касается селектов за скобками я оставляю вопросы обеспечения транзакционности при обновлении базы и прочее. Представьте что ваша программа должна обновлять данные таким образом, чтобы если в любой момент выключится свет данные не пострадали и остались либо в исходном либо в изменненом состоянии. Т.е. вы не можете просто взять и перезаписать текстовый файл (как вы это делали в своей текстовой базе), т.к. если на середине записи выключится свет, зависнет сервер, упадет метеорит, то данные будут полностью утеряны, что недопустимо в современных базах.
Все это вам придется либо реализовать самостоятельно, либо брать какие-то куски откуда-то и пытаться собрать их вместе, но тогда почему просто не взять готовую базу?
Какой объем? Современные базы могут тянуть очень большие объемы, просто нужно мощное железо и правильное индексирование. Какой у вас примерно объем? Сотни тысяч строк? Миллионы? Сотни миллионов? Сразу говорю, если меньше миллиона можете даже не заморачиваться, это даже встроенные БД типа SQL Server Compact проворачивают на напрягаясь. Если десятки-сотни миллионов и нужен полнотекстовый поиск и сложные запросы то тут уже посложнее, но тоже вполне решаемо.
Если нужно кей-валью хранилище есть CoutchDB, MongoDB. Сейчас огромный выбор хранилищ на любой веус и цвет. Писать свое имеет смысл, с моей точки зрения, только либо с целью научиться писать хранилища, либо если есть какая-то очень узкая нишв где ничто не подходит. Но во втором случае вам стоит взять не php, а c++ или эрланг или что-то еще модное, но нативное, а из php цепляться через сокет и слать запросы в каком-то формате.
Хотя если идут в ход аргументы "хочу свой туалет а не стоять в очереди в общественный", то не уверен, что имеет смысл пытаться наставить вас на пусть истинный.
Потому что php интерпретируемый язык. Т.е. нет средств хранения чего-то в памяти. Т.е. даже если вы напишите супер эффективные индексы для вашей БД, то их придется читать каждый раз с диска, а это бешеная нагрузка на I\O, я уж не говорю о том, что без индексов вы вообще сдохните. Поэтому пользователи будут страдать.
Да, для лучшей минификации. Переменная undefined (её значение будет как раз таки undefined, т.к. третий параметр в функцию не передается) также нужна для лучшей минификации. Если вам надо проверить является ли переменная undefined, вы можете либо написать typeof(myvar) = "undefined" и такой код не будет минифицирован, либо сравнить с любой другой, гарантированно undefined переменной.
var a,b;
a===b; //true
Соответственно имея переменную undefined специально созданную для этих целей писать myvar == undefined. Такой код будет минифицирован в myvar == u. Ну и плюс лично мне проверка в стиле myvar == undefined больше нравится чем typeof(myvar) = "undefined, но это дело вкуса.
Ну и что? Открыли себе сокеты и держите их. Зачем вам мучаться с http который предназначен для одной цели - дать ответ на запрос, а не для того чтобы держать постоянный коннект?
Будет много клиентов - нужен будет мощный сервер (серверы). Какие еще варианты? К вконтакте вон сколько народу ломтся узнать нет ли для них какой информации и ничего, живут как-то.
