Хороший тон в SQL
один из вариантов для сиквел сервера:
"странные" вопросы, типа "какое число существительного использовать для названия таблицсчитаю, что имена таблиц должны быть в ед. числе, так как полезной нагрузки мн. число не несет, а над написанием приходится задумываться ( как по правилам образуется множ. число, а может это исключение какое хотя если множественное число использовать только для именования таблиц, то можно по этому признаку отличать таблицы от других объектов, но это imho извращение.
Спасибо за цитату. Правда я половину не понял, но это сейчас не важно...
считаю, что имена таблиц должны быть в ед. числе, так как полезной нагрузки мн. число не несет
Это, конечно, так, но мне всегда особенно приятно, когда конструкции "машинных" языков максимально приближены к естественным, а "SELECT * FROM customer ..." звучит намного более странно, чем "SELECT * FROM customers ...".
считаю, что имена таблиц должны быть в ед. числе, так как полезной нагрузки мн. число не несет
Это, конечно, так, но мне всегда особенно приятно, когда конструкции "машинных" языков максимально приближены к естественным, а "SELECT * FROM customer ..." звучит намного более странно, чем "SELECT * FROM customers ...".
это с одной стороны, с другой стороны глупо предпологать, что в в таблице Customer[s] всего один Customer, посему выходит что смысловой нагрузки множественное число в названии таблицы не несет. а будет таблица city, people, means, basis ..
where Customers.Id = Orders.Id
выглядит хуже
ps
select Name From Order - выбрать поле "имя" из заказа (вроде, нормально звучит)
выглядит хуже
ps
select Name From Order - выбрать поле "имя" из заказа (вроде, нормально звучит)
where Customers.Id = Orders.Id
выглядит хуже
Согласен... Но у того же Граббера (раз уж мы его неявно вспоминаем
) таблицы именуются во множественном числе (да и, кажется, с маленькой буквы(?...
Эврика! Надо писать "SELECT Customer.name FROM Customers Customer ..."
Кстати, насчёт регистра. Таблицам соответствуют классы, имена которых принято писать с большой буквы, а вот атрибутам таблицы соответствуют свойства (члены) класса, а их-то, насколько я понимаю, обычно пишут с маленькой?
выглядит хуже
Согласен... Но у того же Граббера (раз уж мы его неявно вспоминаем
) таблицы именуются во множественном числе (да и, кажется, с маленькой буквы(?...Эврика! Надо писать "SELECT Customer.name FROM Customers Customer ..."
Кстати, насчёт регистра. Таблицам соответствуют классы, имена которых принято писать с большой буквы, а вот атрибутам таблицы соответствуют свойства (члены) класса, а их-то, насколько я понимаю, обычно пишут с маленькой?
public свойства тоже обычно пишутся с большой
Таблицам соответствуют классы............а вот атрибутам таблицы соответствуют свойства (члены) классаОбъясните мне, пожалуйста, эту терминологию. Таблицы не инкапсулируют данные и действия(методы таблицы не наследуются, таблицы не учувствуют в полиморфизме. Так зачем же пользоваться объектно-ориентированной терминологией?
По-моему, “таблицы” правильнее всего называть отношениями, как у кассиков.
Особенно, если учитывать "реляционные базы данных".
---
...Я работаю...
---
...Я работаю...
По-моему, “таблицы” правильнее всего называть отношениями, как у кассиков.
Типа, умный?
Называй, как тебе удобнее.
Так зачем же пользоваться объектно-ориентированной терминологией?
По той же причине: потому, что это удобно и продуктивно.
Обрати внимание: я сказал "Таблицам соответствуют классы"; это ни в коей мере не подразумевает никакого тождества (а, вообще говоря, даже и подобия). /* Если я скажу, что продавцам соответствует таблица `salespeople`, - это не будет означать, что таблица может что-то продать. */
Теперь попробую сказать немного по существу вопроса.
По-моему, трудно игнорировать связь между классами в объектно-ориентированной системе и таблицами базы данных, которую система использует. Наверное, этому способствует тот факт, что и те и другие являются отражением (в соответствующих областях) более общего понятия, которое можно назвать, например, сущьностью. Приступая к проектированию программного продукта, удобно моделировать предметную область, выделяя в ней основные сущности, и исследую возникающие между ними отношения. /* Кстати, заметь, что эти отношения не имеют (AFAIK) никакого отношения к тем "отношениям", которые "у кассиков" */ При написании программы (если мы придерживаемся объектно-ориентированного подхода) удобно моделировать сущности в виде классов, а при проектировании структуры базы данных (если мы используем реляционную модель) - в виде таблиц... Со свойствами объектов, а также отношениями и т.п. - дело обстоит аналогичным образом. С более подробным обсуждением подобных вопросов можно ознакомиться известно где.
Типа, умный?
Называй, как тебе удобнее. Так зачем же пользоваться объектно-ориентированной терминологией?
По той же причине: потому, что это удобно и продуктивно.
Обрати внимание: я сказал "Таблицам соответствуют классы"; это ни в коей мере не подразумевает никакого тождества (а, вообще говоря, даже и подобия). /* Если я скажу, что продавцам соответствует таблица `salespeople`, - это не будет означать, что таблица может что-то продать. */
Теперь попробую сказать немного по существу вопроса.
По-моему, трудно игнорировать связь между классами в объектно-ориентированной системе и таблицами базы данных, которую система использует. Наверное, этому способствует тот факт, что и те и другие являются отражением (в соответствующих областях) более общего понятия, которое можно назвать, например, сущьностью. Приступая к проектированию программного продукта, удобно моделировать предметную область, выделяя в ней основные сущности, и исследую возникающие между ними отношения. /* Кстати, заметь, что эти отношения не имеют (AFAIK) никакого отношения к тем "отношениям", которые "у кассиков" */ При написании программы (если мы придерживаемся объектно-ориентированного подхода) удобно моделировать сущности в виде классов, а при проектировании структуры базы данных (если мы используем реляционную модель) - в виде таблиц... Со свойствами объектов, а также отношениями и т.п. - дело обстоит аналогичным образом. С более подробным обсуждением подобных вопросов можно ознакомиться известно где.
Вот определение “отношения” из математической книжки
Определение 1. Отношением между множествами A и B называется некоторое множество упорядоченных пар <a,b> таких, что a принадлежит A, b принадлежит B.
или
Определение 2. Отношение – подмножество декартова произведения множеств A и B.
(обобщение на бОльшее количество множеств очевидно)
По-моему, нормальному человеку это определение гораздо понятнее, чем определение через туманное понятие “сущность”.
Определение 1. Отношением между множествами A и B называется некоторое множество упорядоченных пар <a,b> таких, что a принадлежит A, b принадлежит B.
или
Определение 2. Отношение – подмножество декартова произведения множеств A и B.
(обобщение на бОльшее количество множеств очевидно)
По-моему, нормальному человеку это определение гораздо понятнее, чем определение через туманное понятие “сущность”.
Я еще не видел ни одного человека, который без подготовки, по данному определению смог бы понять, что речь идет об обычной реляционной таблице.
ps
Интуитивная логика намного больше распространнена, чем высшематическая логика.
Сущность - на основе интуитивной логике, воспринимается довольно легко.
ps
Интуитивная логика намного больше распространнена, чем высшематическая логика.
Сущность - на основе интуитивной логике, воспринимается довольно легко.
1. Спасибо за определения! У меня есть смутное ощущение, что я его где-то видел... Может на первой лекции по матану? 
2. Понятность определения - далеко не критерий эффективности использования определяемой сущности.
3. Я не давал определения.
4. Я не утверждал, что я "нормальный человек".
А если по делу - то...
Это определение и строящаяся на подобных понятиях теория реляционных баз данных - поистине замечательная красивая штука. Вполне возможно, что она позволяет делать далеко идущие выводы, весьма полезные для построения и оптимизации СУБД и т.п. Но не думаю, чтобы эта теория была сильно полезна при разработке прикладного ПО, использующего БД для хранения данных. А вот ООП - совсем наоборот: не строится на строгих определениях, но обладает огромной "убойной силой" при написании "повседневного" софта.
У меня есть смутное ощущение, что я его где-то видел... Может на первой лекции по матану? 2. Понятность определения - далеко не критерий эффективности использования определяемой сущности.
3. Я не давал определения.
4. Я не утверждал, что я "нормальный человек".
А если по делу - то...
Это определение и строящаяся на подобных понятиях теория реляционных баз данных - поистине замечательная красивая штука. Вполне возможно, что она позволяет делать далеко идущие выводы, весьма полезные для построения и оптимизации СУБД и т.п. Но не думаю, чтобы эта теория была сильно полезна при разработке прикладного ПО, использующего БД для хранения данных. А вот ООП - совсем наоборот: не строится на строгих определениях, но обладает огромной "убойной силой" при написании "повседневного" софта.
В книжках всегда даются комментарии к определениям. Если человек не может понять этого определения, зачем он берется за создание информационных систем? Это отнюдь не простое занятие.
Твои "придирки" я опускаю, хотя есть что на них ответить.
По делу.
Оптимизация тут не причем (это дело второго плана). Главное: СУБД (в том виде, в котором они сейчас существуют) своим существованием обязаны реляционной модели.
Что такое “повседневный” софт?
По делу.
Вполне возможно, что она позволяет делать далеко идущие выводы, весьма полезные для построения и оптимизации СУБД и т.п.
Оптимизация тут не причем (это дело второго плана). Главное: СУБД (в том виде, в котором они сейчас существуют) своим существованием обязаны реляционной модели.
Что такое “повседневный” софт?
Твои "придирки" я опускаю, хотя есть что на них ответить.
Как же я тогда буду придираться к ответам на мои придирки?!
Главное: СУБД (в том виде, в котором они сейчас существуют) своим существованием обязаны реляционной модели.
Да здравствуют "СУБД (в том виде, в котором они сейчас существуют)"!
Что такое “повседневный” софт?
Это то, что ты (ну или, скажем, я) мучаешь между двумя очередными чашками кофе, приходя каждый день на работу.
Как же я тогда буду придираться к ответам на мои придирки?!
Главное: СУБД (в том виде, в котором они сейчас существуют) своим существованием обязаны реляционной модели.
Да здравствуют "СУБД (в том виде, в котором они сейчас существуют)"!
Что такое “повседневный” софт?
Это то, что ты (ну или, скажем, я) мучаешь между двумя очередными чашками кофе, приходя каждый день на работу.
Кстати, приведенное мой определение не является строгим. Оно использует понятие упорядоченной пары. В математике можно определить отношение опираясь только на понятие множества. Вот это определение действительно не практично.
а может ты на работе каждый день занимаешься хуйней ?
Может ты дашь определение "повседневного" софта по существу?
? Может ты дашь определение "повседневного" софта по существу?
> Если человек не может понять этого определения, зачем он берется за создание информационных систем?
Затем, что у него это получается достаточно хорошо. И ему за это платят деньги. И не спрашивают - знает ли он математическую основу реляционных таблиц или нет.
Олег правильно заметил, что тонкости реляционной алгебры надо знать в первую очередь тем, кто разрабатывает, оптимизирует работу СУБД.
Тем кто разрабатывает структуру базы достаточно знать те же нормальные формы, можно даже не знать, откуда они берутся.
Тем, кто пишет запросы к БД можно даже нормальные формы не знать.
зы
Простая аналогия: когда ты пользуешься микроволновкой - ты же не думаешь о том, как она устроена, какие теории используются при ее разработки и т.д. .Ты просто жмешь кнопку.
Также и с СУБД. Это такой же прибор (инструмент про который достаточно знать небольшой набор правил для того, чтобы решать большую часть требуемых задач.
Затем, что у него это получается достаточно хорошо. И ему за это платят деньги. И не спрашивают - знает ли он математическую основу реляционных таблиц или нет.
Олег правильно заметил, что тонкости реляционной алгебры надо знать в первую очередь тем, кто разрабатывает, оптимизирует работу СУБД.
Тем кто разрабатывает структуру базы достаточно знать те же нормальные формы, можно даже не знать, откуда они берутся.
Тем, кто пишет запросы к БД можно даже нормальные формы не знать.
зы
Простая аналогия: когда ты пользуешься микроволновкой - ты же не думаешь о том, как она устроена, какие теории используются при ее разработки и т.д. .Ты просто жмешь кнопку.
Также и с СУБД. Это такой же прибор (инструмент про который достаточно знать небольшой набор правил для того, чтобы решать большую часть требуемых задач.
>Также и с СУБД. Это такой же прибор (инструмент про который достаточно знать небольшой набор правил для того, чтобы решать большую часть требуемых задач.
Это применимо к чему угодно. Но претендовать на звание специалиста в этой области в этом случае уже не приходится.
А я так понял, что в этом треде как раз отцы (претенденты в отцы?) этого дела кое-чем меряются.
Это применимо к чему угодно. Но претендовать на звание специалиста в этой области в этом случае уже не приходится.
А я так понял, что в этом треде как раз отцы (претенденты в отцы?) этого дела кое-чем меряются.
Олег правильно заметил, что тонкости реляционной алгебры надо знать в первую очередь тем, кто разрабатывает, оптимизирует работу СУБД.
Еще раз нет. Реляционная модель в первую очередь предоставляет интерфейс для работы с данными. А вопррос оптимизации это вопрос второго плана, хотя и очень важный и без которого рел.СУБД не получили бы такого распространения. Кстати, нереляционная СУБД Cache часто работает быстрее Oracle-а и Microsoft-а даже при запросах на SQL, а если использовать ее внутренние структуры хранения, то ее производительность будет точно больше чем у рел. СУБД.
Ключевое слово --- "Пролог".
---
...Я работаю...
---
...Я работаю...
> Это применимо к чему угодно. Но претендовать на звание специалиста в этой области в этом случае уже не приходится.
ну, и фиг с ним с этим званием, главное, чтобы работодатель/клиенты были довольны
ну, и фиг с ним с этим званием, главное, чтобы работодатель/клиенты были довольны
К сожалению 
, с Прологом я почти не знаком. На сколько я знаю технологии, которые используются в Cahe, возникли еще до реляционной модели. Кто знаком с этим (в частности, с Прологом) расскажите, почему все-таки реляционные СУБД захватили рынок?
, с Прологом я почти не знаком. На сколько я знаю технологии, которые используются в Cahe, возникли еще до реляционной модели. Кто знаком с этим (в частности, с Прологом) расскажите, почему все-таки реляционные СУБД захватили рынок?Ок, спрошу по другому:
что мне, как прикладному программисту автоматизирующему, например, некие бизнес процессы, дает математическое определение таблиц?
что мне, как прикладному программисту автоматизирующему, например, некие бизнес процессы, дает математическое определение таблиц?
Ответ простой: в реляционных базах - низкая стоимость "незапланированных запросов".
Т.е. если мы даже про некий запрос "забыли" на этапе разработки, то его можно легко будет реализовать позже, без особых переделок базы, а также без особых потерь производительности.
Т.е. если мы даже про некий запрос "забыли" на этапе разработки, то его можно легко будет реализовать позже, без особых переделок базы, а также без особых потерь производительности.
Потому что они: легко формализуются, проще при больших объёмах данных, проще в обращении и при всём этом быстры.
Пролог чуть о другом, но может объяснить, почему РБД проста.
---
...Я работаю...
Пролог чуть о другом, но может объяснить, почему РБД проста.
---
...Я работаю...
Что значит
Они -- СУБД. Я тебя так понял, что реляционная теория -- формальная модель. Причем, одновременно с формальностью и простотой, она обладает большой общностью, т.е. с ее помощью можно много чего смоделировать. Это и оценил рынок.
Таким образом, реляционная модель в первую очередь хороша тем, что обладает формальностью, простотой, обобщенностью. А вопросы быстродействия -- вопросы второго плана, хотя без их решениях тоже ничего не получилось бы.
они: легко формализуются?
Они -- СУБД. Я тебя так понял, что реляционная теория -- формальная модель. Причем, одновременно с формальностью и простотой, она обладает большой общностью, т.е. с ее помощью можно много чего смоделировать. Это и оценил рынок.
Таким образом, реляционная модель в первую очередь хороша тем, что обладает формальностью, простотой, обобщенностью. А вопросы быстродействия -- вопросы второго плана, хотя без их решениях тоже ничего не получилось бы.
На больших объёмах ты можешь использовать достаточно удобные средства
откладывания вычислений. Есть прибавка в скорости, при правильных действиях.
---
...Я работаю...
откладывания вычислений. Есть прибавка в скорости, при правильных действиях.
---
...Я работаю...
Всё, иду спать. Завтра, если интересно, продолжим.
Об этом уже много раз говорили, но озвучу еще раз.
Специалистов - отцов нужно очень мало, причем такие специалисты почему-то требуют какие-то бешеные деньги.
Для решения большинства задач требуются специалисты среднего уровня, если понадобится что-то решить сверх этого, то всегда можно пригласить "отца" в качестве консультанта.
ps
ИМХО, вместо того, чтобы заучивать вот такие оторванные от жизни мат. определения, лучше выучить какую-нибудь смежную область, например, экономику, или хотя бы какой-то другой раздел программирования.
Пользы (вероятность применения) будет больше.
Специалистов - отцов нужно очень мало, причем такие специалисты почему-то требуют какие-то бешеные деньги.
Для решения большинства задач требуются специалисты среднего уровня, если понадобится что-то решить сверх этого, то всегда можно пригласить "отца" в качестве консультанта.
ps
ИМХО, вместо того, чтобы заучивать вот такие оторванные от жизни мат. определения, лучше выучить какую-нибудь смежную область, например, экономику, или хотя бы какой-то другой раздел программирования.
Пользы (вероятность применения) будет больше.
А я так понял, что в этом треде как раз отцы (претенденты в отцы?) этого дела кое-чем меряются.Ты неправильно понял. (По крайней мере, я так надеюсь...)
Ты на каком факультете учишься, если для тебя приведенное мною кажется сложным?
Переходим на личности? Больше сказать нечего?
То, что определение "тяжелое" для восприятия - это вывод на основе опыта, я сейчас общаюсь с разным народом - образование самое разное: "заборостроительный", МИФИ, ВМиК, МехМат и т.д.
Многие из них могут и пишут приложения, которые работают с БД, но данного определения они не знают (не помнят). Я даже скажу больше, если им привести данное определения, то они едва ли угадают, что это таблица.
Но это им не мешает писать успешные приложения, и получать за это деньги.
Зачем тогда им это определение, что оно им дает?
ps
Хорошим программистом может быть каждый, даже гуманитарий, но вот в такое определение уже может въехать не каждый. Ну, и зачем оно тогда?
То, что определение "тяжелое" для восприятия - это вывод на основе опыта, я сейчас общаюсь с разным народом - образование самое разное: "заборостроительный", МИФИ, ВМиК, МехМат и т.д.
Многие из них могут и пишут приложения, которые работают с БД, но данного определения они не знают (не помнят). Я даже скажу больше, если им привести данное определения, то они едва ли угадают, что это таблица.
Но это им не мешает писать успешные приложения, и получать за это деньги.
Зачем тогда им это определение, что оно им дает?
ps
Хорошим программистом может быть каждый, даже гуманитарий, но вот в такое определение уже может въехать не каждый. Ну, и зачем оно тогда?
(такие нелюбимые аналогии:)
"Я - пилот самолета. Зачем мне знать законы аэродинамики? Пусть этим занимаются конструкторы. Я только ручки крутить буду!"
Никто от тебя не требует досконального знания теории БД. Но общие закономерности и принципы ты знать обязан.
Чтобы не делать ошибок и писать более-менее оптимальный и стабильный код...
"Я - пилот самолета. Зачем мне знать законы аэродинамики? Пусть этим занимаются конструкторы. Я только ручки крутить буду!"
Никто от тебя не требует досконального знания теории БД. Но общие закономерности и принципы ты знать обязан.
Чтобы не делать ошибок и писать более-менее оптимальный и стабильный код...
> Хорошим программистом может быть каждый, даже гуманитарий
Попахивает "каждой кухаркой, управляющей государством"
В твоей фрезе ошибочное слово "хорошим"...
Попахивает "каждой кухаркой, управляющей государством"
В твоей фрезе ошибочное слово "хорошим"...
Это умение может прийти со временем по методу "проб и ошибок". Но зная внутренюю логику БД и их закономерности еще и в теории, ты сильно эконломишь время и знаешь много полезных алгоритмов...
Так много написал, но так и не ответил, с какого ты факультета?
Зачем тогда им это определение, что оно им дает?Нужно ли определение функции людям, которые занимаются математическим анализом? Твой вопрос аналогичный.
2HG
Ну с 'ом всё понятно: человеку поболтать охото, но ты-то чего?
Никто ж здесь не говорил, что можно профессионально заниматься проектированием БД, ничего не зная про "внутренюю логику БД и их закономерности"! Речь идёт о том, что для того, чтобы хорошо понимать эту логику и закономерности, как правило, достаточно общих принципов (типа нормальных форм которые намного проще освоить на "человеческом" языке, а не на уровне математических абстракций.
IMHO, DarkGrey всё совершенно правильно "разложил по полочкам".
Ну с 'ом всё понятно: человеку поболтать охото, но ты-то чего?
Никто ж здесь не говорил, что можно профессионально заниматься проектированием БД, ничего не зная про "внутренюю логику БД и их закономерности"! Речь идёт о том, что для того, чтобы хорошо понимать эту логику и закономерности, как правило, достаточно общих принципов (типа нормальных форм которые намного проще освоить на "человеческом" языке, а не на уровне математических абстракций.
IMHO, DarkGrey всё совершенно правильно "разложил по полочкам".
...тонкости реляционной алгебры надо знать в первую очередь тем, кто разрабатывает ... СУБД.Ну чего тут ещё оспаривать?
Тем кто разрабатывает структуру базы достаточно знать те же нормальные формы, можно даже не знать, откуда они берутся.
Тем, кто пишет запросы к БД можно даже нормальные формы не знать.
Товарищи IT-специалисты, есть такое понятие как интерфейс, и есть понятие внутренней реализации. Определение отношения необходимо для правильного понимания именно “интерфейса” реляционной модели (см. предыдущее мое сообщение).
ВМиК
> Нужно ли определение функции людям, которые занимаются математическим анализом? Твой вопрос аналогичный.
Смотря, как они занимаются мат. анализом.
Если они толкают матан дальше, то - да, им нужно определение функции.
Если же они матан используют для решения прикладных задач, то определение функции им не надо. Достаточно интуитивного представления.
ps
Ты так и не ответил, чем мат. определение таблицы помогает при разработке структуры базы данных. А также при написании запросов к БД.
А если ничего не дает, то значит это просто информационный мусор.
> Нужно ли определение функции людям, которые занимаются математическим анализом? Твой вопрос аналогичный.
Смотря, как они занимаются мат. анализом.
Если они толкают матан дальше, то - да, им нужно определение функции.
Если же они матан используют для решения прикладных задач, то определение функции им не надо. Достаточно интуитивного представления.
ps
Ты так и не ответил, чем мат. определение таблицы помогает при разработке структуры базы данных. А также при написании запросов к БД.
А если ничего не дает, то значит это просто информационный мусор.
Ты предлагал экономику изучать, так народ над этим . Заметь, я как раз думал противоположное. Конечно, здесь есть доля шутки, но...
Если бы мне для изучения программирования - предложили бы 5 лет оттучится на ВМиК - я бы тоже смеялся. Ну, не учат на ВМиК программировании. Так же, наверное. обстоит дело и на экономическом.
зы
Но я не понял, к чему это ты? Когда я предлагал выучить экономику, я же не предлагал ради этого пойти на экономфак...
зы
Но я не понял, к чему это ты? Когда я предлагал выучить экономику, я же не предлагал ради этого пойти на экономфак...
Если же они матан используют для решения прикладных задач, то определение функции им не надо. Достаточно интуитивного представления.Интересно, что же такое твое "интуитивного представления"? и чем оно отличается от определения функции?
Приведенное мною определение отношения и есть выражение интуитивного представления отношения ().
На твои вопросы в ps попытаюсь ответить после твоего ответа, потому что возможно моего ответа и не потребуется.
К слову. Сейчас читаю "Professional PHP4" (недавно вышедшее 2-е издание и что же мы видим на странице 666...
В системах управления реляционными базами данных (СУРБД) данные организованы в виде таблиц (известных также как "сущности" - entities). Таблицы состоят из полей (известных также как "колонки" или "атрибуты") и записей (называемых также "строками", "экземплярами", "кортежами").Любопытно, что среди такой мешанины терминов "отношение" вообще не фигурирует. Зато оно фигурирует на следующей странице в таком вот контексте.
Данные в таблице обычно логически связаны с данными других таблиц, откуда и происходит термин "реляционные".Сразу хочу предупредить любителей спора ради спора, что я ни в коем случае не ссылаюсь на данную книгу как на сколь-нибудь авторитетный источник в области баз данных! (Хотя в своей области она давно заслужила признание.) Приведёнными цитатами я только хотел показать, как дело обстоит в "реальности" (независимо от наших с вами высоких "поползновений"). Авторы уважаемого источника по программированию на определённом языке (не по БД!) - люди далеко не с улицы (аналитики, проектировщики и разработчики весьма известных компаний) - могут позволить себе даже не знать происхождения термина "реляционные" в применении к БД! (Причём следует учитывать, что книгу писали 16 человек, в ней имеются отдельные главы, посвещённые работе с MySQL, PostgreSQL и ODBC, и странно было бы предположить, что именно эти главы писал человек, не имеющий должного опыта серьёзной практической работы с базами данных.)
> Интересно, что же такое твое "интуитивного представления"? и чем оно отличается от определения функции?
Фенька, которая из одних чисел делает другие числа. Сильно не уверен, что прикладникам нужно более общее (и более точное) определение.
> Приведенное мною определение отношения и есть выражение интуитивного представления отношения (сравни).
Здесь я не согласен с тем, что таблица - это отношение. На интуитивном уровне, в таблице, я никаких отношений не вижу.
Фенька, которая из одних чисел делает другие числа. Сильно не уверен, что прикладникам нужно более общее (и более точное) определение.
> Приведенное мною определение отношения и есть выражение интуитивного представления отношения (сравни).
Здесь я не согласен с тем, что таблица - это отношение. На интуитивном уровне, в таблице, я никаких отношений не вижу.
> Попахивает "каждой кухаркой, управляющей государством"
ИМХО, на данный момент, каждая "кухарка" может программировать (вернее, автоматизировать некие свои рутинные задачи). Для этого не надо каких-либо особых знаний. Причем, желательно этой "кухарке" научится это делать, иначе есть вероятность, что ее обгонять другие.
> В твоей фрезе ошибочное слово "хорошим"...
Согласен, лучше бы там смотрелось слово "удовлетворительным", т.е. достаточно хороши в данном месте и в данный момент. Именно такие программисты и нужны в большом количестве.
ps
Можно провести аналогию с шоферами или преподавателями.
Не каждый человек может стать профессиональным шофером, или преподавателем, но каждый человек водит машину, воспитывает своего ребенка.
А чем тогда отличается программирование?
pps
Программирование - это всего лишь средство, для преобразования наших мыслей на язык машины.
ИМХО, на данный момент, каждая "кухарка" может программировать (вернее, автоматизировать некие свои рутинные задачи). Для этого не надо каких-либо особых знаний. Причем, желательно этой "кухарке" научится это делать, иначе есть вероятность, что ее обгонять другие.
> В твоей фрезе ошибочное слово "хорошим"...
Согласен, лучше бы там смотрелось слово "удовлетворительным", т.е. достаточно хороши в данном месте и в данный момент. Именно такие программисты и нужны в большом количестве.
ps
Можно провести аналогию с шоферами или преподавателями.
Не каждый человек может стать профессиональным шофером, или преподавателем, но каждый человек водит машину, воспитывает своего ребенка.
А чем тогда отличается программирование?
pps
Программирование - это всего лишь средство, для преобразования наших мыслей на язык машины.
Оставить комментарий
yura4773
Есть много советов и соглашений, как "правильно" (= удобно + красиво) оформлять тексты программ на алгоритмических языках (например, C++, PHP...). Вот, скажем, здесь - хороший пример системы таких соглашений. А не подскажет ли кто, где можно найти что-нибудь подобное для SQL? Вопрос немного праздный... да и, конечно, каждый сам выбирает для себя стиль оформления, наиболее отвечающий его эстетическим наклонностям, но всёже никогда не помешает посмотреть на готовый велосипед, прежде чем изобретать свой./* Прежде всего интересует именование таблиц и атрибутов: регистр букв и т.п., соглашения, облегчающие понимание структуры БД и даже "странные" вопросы, типа "какое число существительного использовать для названия таблиц" (напр., `user_profile` или `user_profies`)... */