“[MySQL] Соединения является злым” - Cal Henderson
вы можете попробовать добавить атрибуты вручную, например:
TextBox1.Attributes["type"] = "email";
TextBox1.Attributes["type"] = "url";
TextBox1.Attributes["type"] = "number";
7 ответов
Я несколько преувеличиваю, когда говорю, что они злые.
Для очень больших наборов данных, даже если они умещаются в одной базе данных, объединение - дорогостоящая операция (многие не -последовательный ввод-вывод). При типичной загрузке веб-приложения (чтение / запись 90/10) чтение должно быть как можно более дешевым, в то время как вы можете тратить больше времени на запись (и во многих случаях лениво реплицировать записи). В типичном высокопроизводительном веб-приложении вы захотите выполнить все операции ввода-вывода базы данных за пару сотен миллисекунд, так что это ваш первый предел. Во-вторых, вы хотите иметь возможность выполнять множество одновременных запросов. Это указывает на возможность собирать записи прямо из индекса для больших таблиц. Кто-то уже упоминал, что вам не нужно отправлять в браузер тонны данных, поэтому выполнение соединения по всему набору данных не требуется, но рассмотрите возможность упорядочивания: если вы не можете получить записи в правильном порядке прямо из индекса, вам нужно будет выполнить соединение целиком, прежде чем упорядочить результаты.
Для данных, разделенных на несколько компьютеров, возникают те же проблемы, но в большем масштабе. Обычное решение - это материализованные представления (сглаживание данных), позволяющие выполнять запросы, подобные соединению, путем выполнения нескольких операций записи во время вставки / обновления / удаления (или лениво позже) и с использованием очень простых индексированных выборок.
Очевидно, что соединения полезны и большую часть времени совершенно хороши. Но для больших наборов данных в базе данных, которая изначально не поддерживает материализованные представления, это падает при высоком уровне параллелизма для больших наборов данных.
Все большие масштабируемые системы обходятся без объединения. Причина в том, что в сильно распределенных базах данных, таких как BigTable, которые использует Google, данные настолько велики, что выходят за пределы одной машины. Объединение двух таблиц размером в ГБ никак не масштабируется. Фактически, если вы выполните много объединений, вы увидите около 5 миллионов строк, ваша СУБД начнет грохотать, в значительной степени полагаясь на индексы. Ну, индексы также намного сложнее в распределенных базах данных и базах данных документов, таких как mongodb, couchdb и т. Д.
Будущее - это хорошая архитектурная модель в качестве основы, затем копии данных и после вставки очередей обновления для создания плоских таблиц соединения и обновления при каждом наборы строк изменены. Большие СУБД на MSSQL, Oracle,
Я думаю, что это грубое обобщение. Концепции реляционных баз данных, включая объединения, являются одними из наиболее полезных и ценных инструментов, доступных современному программисту.
Такие концепции, как денормализация для массивных наборов данных, имеют свои достоинства. В наши дни мы склонны принимать слова крупных разработчиков веб-приложений (например, Facebook, MySpace и т. Д.) Как евангелие, не задумываясь о контексте.
Хорошо оптимизированное соединение с индексами и внешними ключами подойдет, если только вы превышают отметку в 300-400 миллионов строк (я не могу говорить о большем, поскольку это примерно предел, с которого мы начинаем архивировать самое большое приложение, над которым я работаю сейчас).
At определенного уровня производительности, вы очень заботитесь о том, сколько раз вам нужно переместить головку диска, чтобы удовлетворить запрос. Чтобы соединить две записи посредством JOIN, вам нужно переместить головки диска как минимум дважды, если только одна или обе записи полностью не удерживаются в индексе, а индекс не кэшируется. (Добавление столбцов в индекс, чтобы столбцы, необходимые для удовлетворения запроса, выходили из индекса, является распространенной техникой, но чем шире кортежи индекса, тем меньше вы можете кэшировать.) И в конечном итоге вы достигаете шкалы, в которой нужные записи для присоединения не находятся под контролем одного и того же экземпляра базы данных.
Я склонен не соглашаться, потому что, если вы хорошо спроектируете свою базу данных, вы сможете добиться высокой производительности. У нас есть многотерабайтное хранилище данных, смоделированное по схеме звезды Кимбалла, и вам нужно ПРИСОЕДИНЯТЬ факты к измерениям, чтобы выполнять любой анализ, и он работает (потому что он секционирован и индексирован). Но мне нужно произвести 200 миллионов строк итогового вывода за один процесс. Такой объем информации просто не будет передан пользователю.
Однако для типичных клиентских веб-приложений, которые возвращают ограниченный объем данных при каждом создании страницы, сколько вы присоединяетесь? Вместо этого ваш сервер приложений может запрашивать строки, а затем запрашивать связанные строки и т. Д. Когда реляционная база данных не была доступна на портативном компьютере 8086 небольшой модели 64 КБ, запрограммированном на C, у нас была библиотека ISAM, и нам приходилось искать и читать в одной таблице, а затем искать и читать в другой таблице. Если вы не имеете дело с большим количеством данных, так же легко выполнить эту работу самостоятельно.
Но это больше программирования, и больше кода означает больше ошибок. Это также означает довольно слабую безопасность базы данных и модель ограничений / реляционной целостности. Без JOIN вы совершите больше обращений к базе данных. В лучшем случае вы вернете такое же количество информации с сервера базы данных на веб-сервер. Ситуация может ухудшиться, если веб-сервер ожидает фильтровать строки по сравнению с предыдущими строками, которые он получил. Фактически, веб-сервер по-прежнему выполняет JOIN, но, конечно, немного проще масштабировать веб-серверы и требуется меньше опыта в оптимизации механизма отношений.
Если вы не имеете дело с большим количеством данных, так же легко выполнить эту работу самостоятельно.Но это больше программирования, и больше кода означает больше ошибок. Это также означает довольно слабую безопасность базы данных и модель ограничений / реляционной целостности. Без JOIN вы совершите больше обращений к базе данных. В лучшем случае вы вернете такое же количество информации с сервера базы данных на веб-сервер. Ситуация может ухудшиться, если веб-сервер ожидает фильтровать строки по сравнению с предыдущими строками, которые он получил. Фактически, веб-сервер по-прежнему выполняет JOIN, но, конечно, немного проще масштабировать веб-серверы и требуется меньше опыта в оптимизации механизма отношений.
Если вы не имеете дело с большим количеством данных, так же легко выполнить эту работу самостоятельно.Но это больше программирования, и больше кода означает больше ошибок. Это также означает довольно слабую безопасность базы данных и модель ограничений / реляционной целостности. Без JOIN вы совершите больше обращений к базе данных. В лучшем случае вы вернете такое же количество информации с сервера базы данных на веб-сервер. Ситуация может ухудшиться, если веб-сервер ожидает фильтровать строки по сравнению с предыдущими строками, которые он получил. Фактически, веб-сервер по-прежнему выполняет JOIN, но, конечно, немного проще масштабировать веб-серверы и требуется меньше опыта в оптимизации механизма отношений.
Но это больше программирования, и больше кода означает больше ошибок. Это также означает довольно слабую безопасность базы данных и модель ограничений / реляционной целостности. Без JOIN вы совершите больше обращений к базе данных. В лучшем случае вы вернете такое же количество информации с сервера базы данных на веб-сервер. Ситуация может ухудшиться, если веб-сервер ожидает фильтровать строки по сравнению с предыдущими строками, которые он получил. Фактически, веб-сервер по-прежнему выполняет JOIN, но, конечно, немного проще масштабировать веб-серверы и требуется меньше опыта в оптимизации механизма отношений.
Но это больше программирования, и больше кода означает больше ошибок. Это также означает довольно слабую безопасность базы данных и модель ограничений / реляционной целостности. Без JOIN вы совершите больше обращений к базе данных. В лучшем случае вы вернете такое же количество информации с сервера базы данных на веб-сервер. Ситуация может ухудшиться, если веб-сервер ожидает фильтровать строки по сравнению с предыдущими строками, которые он получил. Фактически, веб-сервер по-прежнему выполняет JOIN, но, конечно, немного проще масштабировать веб-серверы и требуется меньше опыта в оптимизации механизма отношений.
вы будете возвращать такое же количество информации с сервера базы данных на веб-сервер. Ситуация может ухудшиться, если веб-сервер ожидает фильтровать строки по сравнению с предыдущими строками, которые он получил. Фактически, веб-сервер по-прежнему выполняет JOIN, но, конечно, немного проще масштабировать веб-серверы и требуется меньше опыта в оптимизации механизма отношений. вы будете возвращать такое же количество информации с сервера базы данных на веб-сервер. Ситуация может ухудшиться, если веб-сервер ожидает фильтровать строки по сравнению с предыдущими строками, которые он получил. Фактически, веб-сервер по-прежнему выполняет JOIN, но, конечно, немного проще масштабировать веб-серверы и требуется меньше опыта в оптимизации механизма отношений.По мере увеличения масштаба вы начинаете выбрасывать возможности, потому что они чего-то стоят. Сначала подзапросы; потом со временем даже присоединяется. Это позволит вам делать все, что вам нужно, с таблицами и индексами - например, Google.
Базы данных SQL обычно строятся на isams, которые представляют собой не что иное, как таблицы и индексы. Так что он просто говорит, что приближается к металлу. Что, если подумать, и есть MyISAM. Так вы избавите оптимизатор от необходимости разбираться в этом за вас. И я уверен, что продолжу дальше. Но первым шагом было бы, IMHO, избавиться от накладных расходов на синтаксический анализатор / оптимизатор SQL и напрямую управлять таблицами и индексами. Как это было в foxpro и т. Д.
Присоединение - это стоимость. Вы по-прежнему объединяете или группируете данные и платите за них, но перекладываете затраты на более дешевый уровень приложений, где их легче масштабировать.