Комментарии 28
Сначала прочитал этот ужас (сама статья, а не перевод) — всё скомкано и непонятно. А потом прочитал, что это цикл из 15 статей, и мне стало страшно.
Если действительно хотите подтянуть знания по проектированию баз данных, то читаем — Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. «Базы данных: Учебник для высших учебных заведений». Именно раздел о проектировании, остальная часть уже прилично устарела.
Если действительно хотите подтянуть знания по проектированию баз данных, то читаем — Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. «Базы данных: Учебник для высших учебных заведений». Именно раздел о проектировании, остальная часть уже прилично устарела.
Спасибо за наводку. Буду смотреть. А по поводу статьи. Каждый воспринимает информацию по-своему. При прочтении различных источников что-то может оказаться неясным и в данных статьях, если отделять зерна от плевел, я нашел для себя недостающие кусочки информационной мозаики, при всей, порой, простоте (может и не в лучшем смысле этого слова) изложения. Возможно кому-то это поможет, все мы разные. А не поможет… c'est la vie
Читайте классику citforum.ru/database/osbd/contents.shtml
К слову про фрагмент:
Воркбенч позволяет не только «спроектировать вашу базу данных графически», но и всё остальное что вы делали другими инструментами (SQLyog) и даже больше. Вообще можно было выкинуть всё и использовать только воркбенч.
Существует отличное бесплатное приложение MySQL Workbench. Оно позволяет спроектировать вашу базу данных графически. Изображения диаграмм в руководстве сделаны в этой программе.
Воркбенч позволяет не только «спроектировать вашу базу данных графически», но и всё остальное что вы делали другими инструментами (SQLyog) и даже больше. Вообще можно было выкинуть всё и использовать только воркбенч.
А ведь никто и не спорит. Позволяет, да, равно как существуют и другие программные продукты. Использование тех или иных программ одной направленности — дело вкуса. Я, например, не пользуюсь SQLyog. Но автор статей, очевидно, пользуется и использовать MySQL Workbench в качестве средства графического моделирования — его выбор.
Просто в своё время очень долго искал путёвый универсальный инструмент для работы с MySQL и понял, что лучше Воркбенча вообще ничего нет, а перепробовал я очень многое. Workbench как швейцарский нож.
Вот сейчас работаю преимущественно с PostgreSQL и не хватает инструмента, который был бы как и Workbench, своего рода швейцарским ножом для PostgreSQL. Но к сожалению, пока ничего лучше, чем EMS SQL Manager (Lite версия) не нашёл. Хотя и он не плох, очень даже не плох.
Вот сейчас работаю преимущественно с PostgreSQL и не хватает инструмента, который был бы как и Workbench, своего рода швейцарским ножом для PostgreSQL. Но к сожалению, пока ничего лучше, чем EMS SQL Manager (Lite версия) не нашёл. Хотя и он не плох, очень даже не плох.
Я бы это публиковать на хабре постеснялся.
Вы все не обижайтесь, но если вам это не интересно, то ваш уровень знаний далеко впереди.
Серия статей — для новичков.
Кому-то, надеюсь, это поможет, а это самое главное.
Серия статей — для новичков.
Кому-то, надеюсь, это поможет, а это самое главное.
Как раз для новичков эта статья вредна (кстати, я не заметил в статье ссылки на первоисточник). В принципе, отдельные тезисы верны, но изложение… Статью можно разбирать на цитаты:
Хороший пример. Все верно, не придерешься. Но куда делись UPDATE с DELETE-ом?
Аналогично. Относительно бесплатности MySQL и его открытости (особенно после покупки Oracle-ом) есть разные мнения. По поводу наибольшей популярности, тезис также требует доказательств.
Хммм… А где PostgreSQL? Собственно это в продолжение предыдущей цитаты.
Да ладно, все было не так печально. Например индексы тогда уже были (деталей я за давностью лет уже не помню, но можно посмотреть здесь, мы ведь говорим про CODASYL?). И потом, что значит «бесструктурно», если речь идет о CSV-файлах? Вполне себе структура. Кроме того, замалчивается тот факт, что данные, в то время, хранились на лентах. Соответственно, структуры данных, ориентированные на выборку с произвольным доступом, были не востребованы.
Это быстрее далеко не во всех обстоятельствах. Очень часто полный просмотр выгоднее чем доступ по индексу.
Это самое оригинальное, лаконичное (и очень поверхностное) изложение принципов нормализации БД, которое я видел.
И так вся статья. Изложение поверхностное, неряшливое и местами неточное. Я убежден, что эта статья вредна для начинающих разработчиков и совершенно бесполезна для чуть более опытных. Настоятельно рекомендую переключиться на перевод чего либо более полезного.
База данных создается для хранения в ней информации и получения этой информации при необходимости. Это значит, что мы должны иметь возможность помещать, вставлять (INSERT) информацию в базу данных и мы хотим иметь возможность делать выборку информации из базы данных (SELECT).
Хороший пример. Все верно, не придерешься. Но куда делись UPDATE с DELETE-ом?
РСУБД, которую я использовал для создания таблиц примеров – MySQL. MySQL – наиболее популярная РСУБД и она бесплатна.
Аналогично. Относительно бесплатности MySQL и его открытости (особенно после покупки Oracle-ом) есть разные мнения. По поводу наибольшей популярности, тезис также требует доказательств.
— Oracle – используется преимущественно для профессиональных, больших приложений.
— Microsoft SQL server – РСУБД компании Microsoft. Доступна только для операционной системы Windows.
— Mysql – очень популярная РСУБД с открытым исходным кодом. Широко используется как профессионалами, так и новичками. Что еще нужно?! Она бесплатна.
— IBM – имеет ряд РСУБД, наиболее известна DB2.
— Microsoft Access – РСУБД, которая используется в офисе и дома. На самом деле – это больше, чем просто база данных. MS Access позволяет создавать базы данных с пользовательским интерфейсом.
В следующей части я расскажу кое-что о характеристиках реляционных баз данных.
Хммм… А где PostgreSQL? Собственно это в продолжение предыдущей цитаты.
В 70-х – 80-х годах, когда компьютерные ученые все еще носили коричневые смокинги и очки с большими, квадратными оправами, данные хранились бесструктурно в файлах, которые представляли собой текстовый документ с данными, разделенными (обычно) запятыми или табуляциями.
Да ладно, все было не так печально. Например индексы тогда уже были (деталей я за давностью лет уже не помню, но можно посмотреть здесь, мы ведь говорим про CODASYL?). И потом, что значит «бесструктурно», если речь идет о CSV-файлах? Вполне себе структура. Кроме того, замалчивается тот факт, что данные, в то время, хранились на лентах. Соответственно, структуры данных, ориентированные на выборку с произвольным доступом, были не востребованы.
Компьютерная программа могла бы осуществить поиск в столбце tutorial_id данной таблицы по специфическому идентификатору tutorial_id для того, чтобы быстро найти соответствующие ему заголовок и категорию. Это намного быстрее, чем поиск по файлу строка за строкой, подобно тому, как это делает программа в текстовом файле.
Это быстрее далеко не во всех обстоятельствах. Очень часто полный просмотр выгоднее чем доступ по индексу.
В проекте базы данных, которая создана с учетом правил реляционной модели данных, каждый кусочек информации, например, имя пользователя, хранится только в одном месте. Это позволяет устранить необходимость работы с данными в нескольких местах. Дублирование данных называется избыточностью данных и этого следует избегать в хорошем проекте базы данных.
Это самое оригинальное, лаконичное (и очень поверхностное) изложение принципов нормализации БД, которое я видел.
И так вся статья. Изложение поверхностное, неряшливое и местами неточное. Я убежден, что эта статья вредна для начинающих разработчиков и совершенно бесполезна для чуть более опытных. Настоятельно рекомендую переключиться на перевод чего либо более полезного.
Добротно расписали)
Тоже подумал, «А где же PostgreSQL?». Осмелюсь предположить, что оригинальные статьи очень старые.
И я согласен с вами в том, что статья вредна для начинающих.
Тоже подумал, «А где же PostgreSQL?». Осмелюсь предположить, что оригинальные статьи очень старые.
И я согласен с вами в том, что статья вредна для начинающих.
а Sybase где? обидно однако…
За Sybase тоже обидно, но он не бесплатный. А про MySQL утверждается что он чуть ли не самый популярный и бесплатный, что несколько не соответствует действительности.
Надо PostgreSQL, дабы у новичков не складывалось неправильное представление об арсенале бесплатных РСУБД
Что еще надо ?
Надо PostgreSQL, дабы у новичков не складывалось неправильное представление об арсенале бесплатных РСУБД
Вообще предпочтительнее начинать, как мне кажется, именно с PostgreSQL, а не с MySQL. Функционал значительно шире и зная PG можно будет быстро разобраться с остальными. Например, работа с теми же самыми хранимыми процедурами, которых нет в MySQL. Ещё вьюхи, не зависимая от типа таблиц возможность использовать внешние ключи и т.п.
Вот вы являетесь наглядным примером того, что зная PG в MySQL не смогли разобраться dev.mysql.com/doc/refman/5.0/en/stored-routines.html
Соответственно ценность вашего мнения близка к вашей оценке наличия хранимых процедур в MySQL — нулевая.
Соответственно ценность вашего мнения близка к вашей оценке наличия хранимых процедур в MySQL — нулевая.
Согласен, лажанул.
Сейчас настрочил длинное оправдание, но подумал, кому это надо и стёр его:-)
В общем, в последний раз с MySQL я работал довольно таки давно, но уже тогда была версия 5.x, вот точно непомню, скорее всего одна из первых. И в данный момент мои знания о MySQL, видимо, просто ничтожны, т.к. уже давно перестал работать с ним и слежу теперь больше за обновлениями PG.
После MySQL пришлось столкнуться с Firebird, SQLite и, собственно PG. И последний привёл меня в дикий восторг. PG в некоторых местах заставляет думать по-другому. И у меня возникла мысль, что, если бы я начал не с MySQL, а с PG, то, скорее всего у меня бы остались совершенно другие впечатления от MySQL.
В общем можно гадать о том как было бы, но моё мнение (ИМХО), мне надо было начинать с того от чего мои впечатления были лучше.
P.S.: каюс, надо было пробежаться по документации MySQL, прежде чем писать.
Сейчас настрочил длинное оправдание, но подумал, кому это надо и стёр его:-)
В общем, в последний раз с MySQL я работал довольно таки давно, но уже тогда была версия 5.x, вот точно непомню, скорее всего одна из первых. И в данный момент мои знания о MySQL, видимо, просто ничтожны, т.к. уже давно перестал работать с ним и слежу теперь больше за обновлениями PG.
После MySQL пришлось столкнуться с Firebird, SQLite и, собственно PG. И последний привёл меня в дикий восторг. PG в некоторых местах заставляет думать по-другому. И у меня возникла мысль, что, если бы я начал не с MySQL, а с PG, то, скорее всего у меня бы остались совершенно другие впечатления от MySQL.
В общем можно гадать о том как было бы, но моё мнение (ИМХО), мне надо было начинать с того от чего мои впечатления были лучше.
P.S.: каюс, надо было пробежаться по документации MySQL, прежде чем писать.
Спасибо за перевод.
еще вот хорошая и толстая книга
Системы баз данных. Полный курс — Гектор Гарсиа-Молина, Джеффри Ульман, Дженнифер Уидом
www.ozon.ru/context/detail/id/1351096/
Системы баз данных. Полный курс — Гектор Гарсиа-Молина, Джеффри Ульман, Дженнифер Уидом
www.ozon.ru/context/detail/id/1351096/
Спасибо. Оглавление вызывает интерес.
А на курсере еще есть стэнфордский курс по базам данных от Дженнифер Уидом
class.coursera.org/db/class/index
class.coursera.org/db/class/index
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, несколько лет назад я искал такой текст, но ничего не нашел. Может, плохо искал. Так или иначе, общую картину пришлось собирать самостоятельно из разрозненных фрагментов.
Почитал каменты — на самые лучшие статьи больше всего хейтеров слетается, Хабр превратился в унылое гнездо сетевых пидарасов :D
За текст — спасибо! Годнота.
За текст — спасибо! Годнота.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство по проектированию реляционных баз данных (1-3 часть из 15) [перевод]