LINUX.ORG.RU
ФорумTalks

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

 , ,


0

1

Посоветуйте пожалуйста актуальные и на Ваш взгляд полезные по SQL книги. В данный момент сам для себя пишу сайтик заметок на Java+SQLite , столкнулся с тем чего не ожидал :) Книги не обязательно должны быть привязаны к конкретной БД, принцип то в основном один.
SQL в универе на заочке с легкостью сдал и впечатление в голове сложилось, что вполне все просто, а тут оказалось, что все не так просто с проектированием нормального рабочего проекта, а не учебной поделки.

Ответ на: комментарий от makoven

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

vik24rus ()

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

crutch_master ★★★★★ ()
Ответ на: комментарий от vik24rus

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

crutch_master ★★★★★ ()
Ответ на: комментарий от crutch_master

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

vik24rus ()
Ответ на: комментарий от vik24rus

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

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

makoven ★★★★★ ()
Ответ на: комментарий от vik24rus

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

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

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

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

crutch_master ★★★★★ ()
Ответ на: комментарий от vik24rus

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

crutch_master ★★★★★ ()

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

Wizard_ ★★★★★ ()
Ответ на: комментарий от makoven

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

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

anc ★★★★★ ()

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

makoven ★★★★★ ()
Ответ на: комментарий от makoven

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

anc ★★★★★ ()
Ответ на: комментарий от anc

1. view

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

2. sp

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

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

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

makoven ★★★★★ ()
Последнее исправление: makoven (всего исправлений: 4)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.