Книги для изучения БД

Use ORM

про ORM и DAO я в курсе. Хочу начать с DAO, потом перейти в ORM. Что бы понимать, как внутри все работает + иметь опыт написания sql запросов.

Открываешь мануалы субд с которой собираешься работать и читаешь до получения просветления. Раз с sql ты знаком, то проблем не будет.

Верной дорогой идешь, понимание работы субд очень пригодится, когда всё это orm/dao-говно начнёт лагать и тормозить.

вот в том то и дело, что знаком, хотелось бы книгу (книг) по языку запросов SQL и с теорией о том как правильно нормализовать данные, как ее правильно спроектировать, что бы в дальнейшем при эксплуатации было наименьшее кол-во проблем )

Что бы понимать, как внутри все работает

Очень муторно работает. Собирать руками данные, размазанные по дюжине таблиц, приведенных к 3НФ - то еще удовольствие

как ее правильно спроектировать

БД невозможно спроектировать правильно. В процессе эксплуатации обязательно всплывут какие-то нюансы, о которых никто не догадывался.

о том как правильно нормализовать данные

Я думаю ты и так знаешь, как распихать данные по таблицам и сделать ключи. Вопросы в эксплуатации другие. Например, таблица разжирела, индексы со слона, отсюда - тормоза etc. Или данные приходят откуда-то и надо к ним приделать уникальный id и как-то обновлять. Или приходят сырые данные без ключей и там одно и тоже называется по-разному. Короче, не парься. С субд у тебя проблем будет меньше всего.

Я свою первую БД проектировал почти сразу после шараги и даже не смотря на все моё косоручие она сносно эксплуатировалась/чинилась. Главное данные не просрать, а распихать их по таблицам - дело двух запросов.

Книги не знаю. Хороший тутор http://sqlbolt.com/

http://mexalib.com/?id=15163

Крис Дейт написал несколько хороших книг по реляционкам.

Собирать руками данные, размазанные по дюжине таблиц, приведенных к 3НФ - то еще удовольствие

Пуф. Тоже мне проблему нашли. Давайте вообще без нормализации жить. Не, а че? Вон все веберы так строчат код. Норм все. Компы мощнее, мозгов больше, ошибок больше, упс, да я на х... вертел ваши данные, опять не так, мамаааа опять данные не сходятся, у мэна все работает и не партите мне мозг.
Но вот что запомнилось из прочитанной теории. Кто-то писал что 5НФ конечно интересна, но в жизни не применима, и я с этим согласен.

Ищите не SQL (это язык управления данными, он не дает понятия как надо хранить данные). А теорию реляционных БД. А сикул, сам подтянется.

Я же не против нормализации. а про то, что муторно вытягивать голыми SQL-запросами данные, размазанные по десятку таблиц, большинство из которых созданы исключительно для того, чтобы уйти от many-to-many связей

1. view
2. sp
3. для не частых и изменяемых запросов, просто держим в девел. шаблоны

1. view

Еще бы вставлять в них можно было. Чтобы сериализовал плоский объект из ЯП во вьюху, а оно внутри базы само размазалось по промежуточным табличкам

2. sp

Ребята, не стоит вскрывать эту тему

Хотя я с вами, чуть-чуть, именно «чуть-чуть», согласен в части «муторно». Достаточно год не поработать с какой-то структурой что бы подзабыть. :) И сначала приходиться вспоминать, а что же мы там сделали? :) Но это «чуть-чуть» в разы перекрывает саму реализацию. Сам иногда удивляешься, «хрена себе чего предусмотрел». Но бывает и обратное «вот долбодятел, как ты такое мог не предусмотреть?». Мне наверное «повезло» «второго» очень мало досталось.

Я пару раз начинал делать абстрактный слой, внутри которого SQL-запросы. Но где-то в глубине всегда естественным образом самозарождался недо-ОРМ. Начиная с db.select('users', name='Ivan'). Заканчивая цепочками таких методов. Просто потому, что голый SQL в коде смотрится громоздко, а хранить каждый запрос в отдельном файле - много чести

Ну и результат хочется сразу в объекты, а не в список rows, которые потом рутинно распихивать по объектам, тем самым грубо нарушая принцип DRY